svn commit: r259016 - in head/sys: conf dev/drm2 dev/drm2/i915 dev/drm2/radeon dev/fb dev/vt kern modules/drm2/i915kms modules/drm2/radeonkms sparc64/sparc64 sys teken

[Aleksandr Rybalko]

On Mon, 09 Dec 2013 18:26:46 -0600
Nathan Whitehorn <nwhitehorn at freebsd.org> wrote:

> On 12/09/13 18:20, Aleksandr Rybalko wrote:
> > On Sun, 8 Dec 2013 16:36:20 +0100
> > Marius Strobl <marius at alchemy.franken.de> wrote:
> >
> >> On Thu, Dec 05, 2013 at 10:38:54PM +0000, Aleksandr Rybalko wrote:
> >>> Author: ray
> >>> Date: Thu Dec  5 22:38:53 2013
> >>> New Revision: 259016
> >>> URL: http://svnweb.freebsd.org/changeset/base/259016
> >>>
> >>> Log:
> >>>    Merge VT(9) project (a.k.a. newcons).
> >>>    
> >>>    Reviewed by:	nwhitehorn
> >>>    MFC_to_10_after:	re approval
> >> Have you addressed any of the points raised in:
> >> http://lists.freebsd.org/pipermail/freebsd-current/2013-October/045887.html
> >> to get VT(9) at least en par with syscons(4) regarding being able to
> >> use a hardware cursor, allowing different low-level console drivers
> >> to compete for the same hardware etc. in the meantime?
> >>
> >> Marius
> >>
> > Hello Marius!
> >
> > Yes and No :)
> >
> > Lets make it as list with short items:
> > 1. Making these drivers work as low-level console.
> > 2. Drivers priority.
> > 3. Using hardware acceleration.
> > 4. Using the 12 x 22 gallant font.
> > 5. Allowing Xorg to map the frame buffer.
> > 6. (Part of 5) Other register banks as needed.
> > 7. Allowing late attachment.
> >
> > Answers:
> > 1. Works, I did testing on ARM board Efika MX with vt_fb_early driver.
> > (Still have to discuss several things with arm@ guys, then commit)
> 
> As I mentioned in my review, this particular code is a really weird 
> bug-filled copy of ofwfb.c, which already works as a low-level console 
> early in the boot process.

TODO :)

> 
> > 2. Works. F.e. amd64 start with vt_vga driver, then vt_kms driver
> > override it as more specific.
> 
> I think Marius meant having early-boot drivers bid amongst each other 
> for attachment....

Early-boot drivers selected on console driver bid rules. I see early
drivers as something really special, because resource management is not
ready at this stage and many device even is not able to get all
required info to be initialized fully. So I prefer model with simple
driver like vt_fb_early which is replaced later by full functional and
allocated by kernel's resource management rules.

> 
> > 3. Not used at all yet.
> >
> > 4. I like that font. If you want more "gallant" - I will help. Thanks
> > to Ed, newcons support any font dimensions.
> >
> > 5. It works, but only for those drivers which attach dev/fb/fbd, via
> > fbd devfs node (not accessible via vt(9) ioctls yet).
> 
> Could you provide more detail about how this is supposed to work? X 
> doesn't map at offset 0 in general, and that means that 100% of X UMS 
> drivers are currently broken with newcons.

I already done framebuffer info export and mmap support to ttyvX
devices. Just xboxfb/ofwfb drivers is not ready yet.
Phrase "100% of X UMS drivers" is totally incorrect :)
PC like systems use direct access to video drivers, but not maps fb.
Only ppc/sparc64 support mmaping of vt devices (at least before I start
to work on Efika MX, now RPi and Efika MX here too).

But found one more problem here :)
Xorg with vesa driver left video in VESA mode on exit, so I add restore
VGA mode for vt_vga driver on vt switch.

Since I made framebuffer export works for all framebuffer provider it
will be supported after small modifications to xorg-server port.
x11-drivers/xf86-video-scfb already committed to ports tree (great
thanks to Rene Ladan), but limited yet to not PC platforms, until xorg
not ready.

> 
> > 6. IMO better to put it into some drm emulation.
> >
> > 7. Works in many combination. (
> > start w/ vga, load kms; (kms replace vga)
> > start w/o driver, load kms;
> > preload kms, start w/ vga; (kms replace vga)
> > preload kms, start w/o driver; (kms attached after drm node initialized)
> > )
> >
> > Have to put your list on Newcons's wiki page too.
> >
> > As I remember such long list of requirement you provide was based on
> > expectation that I want to replace syscons right now :)
> > But, for now we (me and x11 team) want to see it 10.0 as disabled by
> > default (just like in HEAD now), so peoples who want to help with debug
> > of new xorg and drm drivers will be able to see messages after KMS-xorg
> > starts.
> >
> > Oh, looks like I forget what I have to say more. :)
> > So it will be said later, when I will less sleepy.
> >
> > Anyway. Thanks a lot for your comments!!!
> >
> > WBW
> 
> We should come up with a sunset plan for syscons, though.

TBD

> -Nathan

Thanks a lot!

WBW
-- 
Aleksandr Rybalko <ray at freebsd.org>