Subject: Re: framebuffer access
To: None <port-sparc64@NetBSD.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: port-sparc64
Date: 11/16/2005 12:08:05
>>> wsdisplay was never meant to be a framebuffer device,
>> In that case, it would be nice if the ``text'' mode framebuffer were
>> smart enough to drop into ddb while X is running.
> This requires someone telling the driver about it.
> The problem with switching consoles is - if one console is in
> graphics mode you need to tell the program hogging it to let go, wait
> for an ack, then switch.  Forcing a switch WILL break things since
> there's no such thing as virtualization in any meaningful way.

Then it seems to me that the right thing to do is to add such
virtualization.

Yes, different framebuffers have different needs.  That's what drivers
are for: to encapsulate hardware-specific knowledge and provide a
hardware-independent interface.  (This is not to say that it's
necessarily easy enough to be worth doing, especially in ports saddled
with peecee video board hell.  Just that it's pretty clearly, to me,
the Right Way.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B