newcons comming
Marius Strobl
marius at alchemy.franken.de
Sun Oct 27 21:02:43 UTC 2013
On Fri, Oct 25, 2013 at 03:18:47PM +0300, Aleksandr Rybalko 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.
Could you please port at least either creator(4) or machfb(4) to newcons
before it even hits head so we don't have the same situation as with
syscons again where we need to make square pegs fit into round holes? My
main concerns in this regard are:
o Making these drivers work as low-level console in the syscons sense so
they already work for printing the Copyright notice of the kernel. The
problem here is that the respective chips don't necessarily come up with
the frame buffer mapped and we can't do that on our own at that point with
the VM not up, yet. So all access has to be done via bus_space_*(9) and
specially crafted bus tags and handles. In short: Except for some specific
model and firmware combinations, in general the generic OFW frame buffer
approach doesn't work here, that's why these drivers exist in the first
place.
o For coexistence of f. e. machfb(4) with ofwfb.c, allow some probing of
drivers in the BUS_PROBE_GENERIC/BUS_PROBE_DEFAULT etc. manner. The
crucial point here is that in case a more specific driver is willing
to attach to a certain device, a generic driver must not touch the
hardware in any way. It seems that vd_priority is too late in the game
for that requirement. With syscons, this is achievable by letting the
generic driver call vid_configure(VIO_PROBE_ONLY) and then check whether
another driver has taken the device.
o Using hardware acceleration for drawing characters and the mouse pointer,
i. e. using a hardware cursor. Employing the respective chips as "dumb"
frame buffers instead is just dog slow. Currently, I don't see how a
hardware cursor could be hooked up to newcons. The current putc code in
these drivers _might_ be suitable for implementing bitbltchr methods.
Apart from that these chips also can do simple bitblt etc. of course.
o Using the 12 x 22 gallant font.
o Allowing Xorg to map the frame buffer but additionally also other register
banks as needed through newcons. With syscons, a driver can provide a
mmap method for that (see machfb(4). I currently don't see how to do that
with the newcons infrastructure. An alternative might be to make Xorg/
libpciaccess aware of newcons and go through a /dev/fdX in that case.
Still, I don't see how to currently do that for resources besides the
actual frame buffer with existing fdc.c. I'm also not sure whether the
latter is the appropriate route to go in the first place given that
besides mmap'ing from userland, newcons'ified creator(4) and machfb(4)
still should be used directly.
In any case, for creator(4) Xorg expects a /dev/fdX anyway.
o Allowing late attachment in case the primary console is the serial one,
another graphics chip etc. during regular device attachment when everything
needed (mainly the VM) to bring the frame buffer fully online on our own
is available. Is that what vt_allocate() is for?
Marius
More information about the freebsd-current
mailing list