Edward Shu wrote:
>
> I think there are two concepts to be clarified, VGA text console
> and VESA text console. VGA text console is the legacy way.
> In this proposal, you may mean the VESA text console when
> text console is mentioned, that emulates the text output with
> the VESA graphics mode. As VESA is a generic graphics
> standard with few hardware specific acceleration, the text
> rendering speed will be much slower causing flicking screen.
It actually depends on the card. By setting the framebuffer memory as
cache combined, memset/memcpy (thus, video painting) are pretty smooth
on a lot of recent hardware, also on long scrolling.
We also 'pick' 16-bit modes over 32-bit modes in the 'automatic' mode
selection so that half of the amount of memory needs to be moved around
on scrolling. (I don't see any particular reason for a user to need a
32-bit console framebuffer, but he can choose so by directly using the
vbeset command in GRUB)
> I recommend to reserve some open interfaces for third-party to
> fully accelerating the text rendering under VESA text mode.
There is an experimental interface for that that I placed in the code. A
driver can call 'gfxp_fb_register_fbops' to register blit, copy, clear,
setmode, etc operations. It can also just register a small number of
them and let the code use the standard ones for the other operations
(simply, set the function pointer to NULL). I would keep it
experimental: we don't have many drivers in general (and they behave
already somehow differently, e.g. nvidia vs intel). If we get to the
point where we have more drivers we may reconsider a larger redesign of
how the framebuffer is managed (e.g. specific DDI/DDK functions?).
> Other comments in lines below.
>
>> 2.5) Resetting frame buffer state on fast reboot
>>
>> Since the boot loader does not run during fast reboot, the kernel
>> needs to ensure that the graphics card is in a sane state. This is
>> achieved by setting the appropriate mode early on while the system
>> can still make BIOS calls.
> I am not sure you can find a right place to make the BIOS calls, because
> fast boot will be out of the real mode very early.
>
We can go back to real mode for some time during normal boot. The
interface is bop_doint. It basically maps a stub of code at low
addresses and switches back to real mode to execute the interrupt. The
fastreboot code already uses it since the putback for 6855522, we have
just extended it (I can point you - and anyone who wants to - to a
webrev if you wish so).
>>
>> 2.6) Resetting frame buffer state on suspend/resume
>>
>> Since userland must be running for vbiosd to reset the mode, the
>> mode can not be reset directly as part of the resume entries. Rather
>> another thread in the daemon, is invoked that is pause()d with a
>> SIGTHAW
>> handler that will send a KD_RESUME ioctl to the console device when
>> invoked, which in turn invokes the vbiosd door thread to set the
>> proper
>> VESA mode.
> We actually have a srn driver to communicate with the X server to do
> suspend/resume.
> The srn driver protocol can be enhanced for vbiosd to act likely.
>
One thing we really want to catch is when the userland comes back alive,
since vbiosd is a userland process. Is there a way to get that from the
driver protocol apart the SIGTHAW?
Is there more in the driver protocol than getting our suspend and resume
functions called ? If so, I would be very interested in checking that.
- Enrico
