Re: OpenGL-based framebuffer concepts

["D. Hazelton" <dhazelton@enter.net>]

On Tuesday 23 May 2006 23:38, Jon Smirl wrote:
> On 5/23/06, Matthew Garrett <mgarrett@chiark.greenend.org.uk> wrote:
> > Jon Smirl <jonsmirl@gmail.com> wrote:
> > > 1) Running the video ROM at boot to reset cards, emu86
> >
> > Jon, how many times am I going to have to tell you that this won't work?
> > The video ROM is not always present on laptop hardware, and even when it
> > is it may jump into sections of ROM that have vanished since boot.
> > In the long run, graphics drivers need to know how to program cards from
> > scratch rather than depending on 80x25 text mod being there for them.
>
> 1) I didn't put a lot of detail into the line item but you only need
> to use the ROM to reset secondary cards on x86 architectures. Primary
> cards are always initialized by the system BIOS so you don't need to
> run their ROM on boot. I think the only way to get a secondary card
> into a laptop is through a PCMCIA slot and I've only seen one PCMCIA
> video card.

Agreed. I'll see about doing this using a method similar to the X int10 model. 
I don't have access to the specs on anything other than x86, so if someone 
could provide some information to help with the non-x86 side of the code I'd 
be grateful.

> 2) The ROM support in the kernel knows about the shadow RAM copy at
> C000::0. When you request the ROM from a laptop video system it
> returns a map to the shadow RAM copy, not to a physical ROM. You need
> access to the shadow RAM copy to get to things the BIOS left there
> when it ran.

Of course. But then there are people who do stupid things like telling the 
BIOS not to provide a shadow copy of the ROM. However that isn't a big 
problem and those people should have their hardware properly configured in 
the first place...

> So to add more detail,
> Run the ROM on primary adapters if the arch is non-x86 and the ROM
> contains x86 code.
> Run the ROM on primary adapters on embedded systems if the system BIOS
> doesn't do it.
> Otherwise don't run a primary ROM. The kernel ROM API tracks primary
> versus secondary for you.
> Always run the ROM on secondary adapters. Secondary adapters don't
> have the compressed laptop ROM problem.

Okay. This is good - exactly what I was thinking would be done anyway.  What 
about cards like the Radeon's with two CRTC's that can run multi-headed off a 
single card?

Apparently the card is booted properly by the BIOS, but the second head 
(either the VGA port, the Composite/TV Out or the DVI) isn't setup properly 
by the BIOS because, apparently, the ROM can't detect the properties of the 
second head in some situations.

However, for situations like that it might be best to have the API open so 
that userspace tools can be used to set those secondary outputs.

> When running the ROMs you will need to add code to manage the active
> VGA device since both adapters will try and turn it on when their ROMs
> are run.

Okay. This has me beat - any suggestions on how to manage it?

> You will also need to provide a mechanism to call out to userspace.
> The userspace program will use vm86 or emu86 to run the ROM image.

Yes - problem is that I have not been able to find any decent information on 
vm86/emu86 in order to capitalize on the system call. Might be better to have 
some people specifically working on the userspace stuff while others focuse 
on the in-kernel stuff.

> The contents of the ROM image should be put back into the kernel using
> the ROM copy APIs but no one has gotten that far yet. Video ROMs
> assume they are running out of shadow RAM so they alter things and
> leave pointers to what they found.
>
> I can provide more detail on how to set all of this up if needed.

Yes, please. I made the post I did - dumping my immediate thoughts on the 
subject into it - because I was interested in working on this and making some 
contribution to the kernel. I have a feeling I can get the DRM stuff working 
as the backend for the framebuffer drivers and export that API, or something 
slightly different, to userspace for the userspace tools to take advantage 
of.

In this case, I was thinking that the exo-kernel model used in ALSA would be 
the best solution. For that matter, it wouldn't be trivial, but your 
suggestion about modifying Mesa to be the main userspace interface to the 
kernel graphics system has a lot of merit.

One problem is that Mesa is strictly OpenGL, so this would mean there would 
have to be a second library for the 2D stuff. Potential contenders for this 
are abundant, including one windowing system that actually, IIRC, is 
distributed as a kernel patch/module. I would love to leave the 2D stuff 
completely up to userspace, but all modern video cards contain acceleration 
for 2D drawing, so it would probably be best to include that in any userspace 
side of the system.

DRH