Re: newcons comming

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