Re: newcons comming

On Fri, 25 Oct 2013 18:46:02 +0300
Konstantin Belousov <kostikbel_at_gmail.com> wrote:

> On Fri, Oct 25, 2013 at 04:04:10PM +0300, Aleksandr Rybalko wrote:
> > On Fri, 25 Oct 2013 15:18:47 +0300
> > Aleksandr Rybalko <ray_at_ddteam.net> wrote:
> > 
> > > Hello fellow hackers!
> > > 
> > > I finally reach the point when I can work with newcons instead of
> > > syscons on my laptop. Yes, I know it still buggy and have a lot of
> > > style(9) problems. But we really have to get it into HEAD and
> > > 10.0 to enable shiny new Xorg features, drivers, etc.
> > > 
> > > So I ask everyone to look "hard" into that[1] and tell me your
> > > opinion. I expect a lot of opinions, since it have to affect
> > > almost all good guys, as result I have to ask to split "bug
> > > reports" into two parts:
> > > 1. Should be done before merge to 10.0;
> > > 2. Can be done later.
> > > 
> > > If it possible, please do it(review - report) ASAP.
> > > I have plan to done it that way:
> > > 1. Merge newcons to head (in a few days);
> > > 2. Fix a lot of reported bugs (2 hrs :-D );
> > > 3. Persuade re_at_ about we need it in 10.0 (one week, maybe two);
> > > 4. Merge to 10.0;
> > > 5. One year AFK somewhere on Bahamas;^W^W^W^W^W^W^W
> > > 5. Add mouse cut-paste support;
> > > 6. Fix new bugs;
> > > 7. Some drinks.
> > > 
> > > What do we will have with newcons:
> > > * (Think it is main) Allow us to switch to fresh Xorg, which
> > > require KMS.
> > > * Graphic devices which can provide framebuffer access can be
> > > easily used as virtual terminals (someone may have pixel-LCD on
> > > front of PC tower, may found it useful :-D )
> > > * See [2].
> > > 
> > > TODO:
> > > * Lack of key mapping files, everyone can help with that using
> > > instructions on [3];
> > > * A bit slow (mostly scrolling affected).
> > > * Other bugs :)
> > > * See [2].
> > > 
> > > Thanks!
> > > 
> > > [1] - http://svnweb.freebsd.org/base/user/ed/newcons/
> > > [2] -
> > > http://www.freebsd.org/news/status/report-2013-07-2013-09.html#Continuation-of-the-Newcons-Project
> > > [3] -
> > > http://raybsd.blogspot.com/2013/10/newcons-international-keyboard-input.html
> > > 
> > > Hope you will love newcons!
> > > And maybe me too :)
> > > 
> > > WBW
> > > -- 
> > > Aleksandr Rybalko <ray_at_ddteam.net>
> > 
> > Forget to give a patch to HEAD, here it is:
> > 
> > http://people.freebsd.org/~ray/newcons/newcons_to_head_r257107_2013-10-25_1542.diff.gz
> 
> Was the code reviewed by anybody ?  Was technical reviewer assigned by
> the project sponsor ?

Yes, technical reviewer assigned, but project code is not reviewed yet.
That why I'm not commit it to HEAD right now :)
I will cleanup it few days, then will ask for review and do CFT call
too.

> 
> I looked very quickly over the whole patch, I only enumerate the
> things that catched my eye:
> 
> dev/vt/hw/intel.c is sort of joke, it should be removed.

It is more than joke! :)
Leftover from old project. I've already remove it after your notice.

> 
> I am very suspicious to what you do in the drm_fb_helper.c with
> enqueuing, but I need to do much more reading of the code to say
> something definitive.

I think you mean use of EVENTHANDLER.
Describe a little why it here first:
Since some time both VTs must be present (syscons and newcons), but
framebuffer born inside drm2 module, I have to make it completely
independent from presence of newcons. 

Few days ago I already collect some opinions in that case. And "public
opinion" give me answer - "best to use newbus here", but I recall more
simple way - EVENTHANDLER. I did implement it. Later, I found more and
more argument that points to newbus.
F.e.: after suspend it Xorg draws better if machine suspend/resume in
terminal(Xorg on inactive terminal), it is just because Xorg after
resume gets notification about activation of its terminal window, so it
redraw screen. So I have to use newbus's _suspend/_resume to notify
clients.


> 
> Intel GPU might provide relatively wide range of the pixel formats, I
> do not see a code to parse and use these formats.

Yes, but nobody use anything than RGB+ARGB, maybe with exception of TV
output. Newcons's have infrastructure support for that, so required
format can be easily added.

> 
> Overall code looks relatively self-contained, so I think you indeed
> might merge it to head after some public testing and review.  But I
> very much doubt that 10.0 is feasible for any efforts.

Ok, lets do everything sane, then to decide :)

Looks like I can even make it coexistent with syscons, so if user load
KMS enabled module, newcons will attach over syscons. Think it is good
way to HEAD users/developers to see what happen on xorg crash.

So no rush, just work. :)

Many thanks for opinion!

WBW
-- 
Aleksandr Rybalko <ray_at_freebsd.org>