After talking to many people at OLS this seems to be the consensus for
rearchitecting fbdev/DRM. It has been proposed that this design be a
five year goal but there is still disagreement about the exact path to
get there.
This is a first pass for the fbdev/DRM people. I will incorporate
comments
On Mer, 2004-07-28 at 19:53, Jon Smirl wrote:
First a basic definition. There are two consoles, the kernel one
(printk, kdbg, OOPs, etc) and user one (normal console logins). There
is no requirement that these consoles be handled with the same code
even though they are today.
Not sure that
On Mer, 2004-07-28 at 22:31, Kronos wrote:
There was a thread on acpi-devel about POSTing VGA ROM after resume:
http://marc.theaimsgroup.com/?l=acpi4linuxm=109023076427394w=2
The code does a real mode switch in kernel and execute the ROM. Ok, doing
that in userspace is more elegant, but
--- Alan Cox [EMAIL PROTECTED] wrote:
sysfs? I sent a patch a while ago but didn't get much feedback.
How do you atomically tie sysfs objects to fbdev and X permissions
models ?
I think the plan here is for ROM export to be implemented by the PCI
driver not the video ones since other things
Alan Cox wrote:
On Mer, 2004-07-28 at 22:31, Kronos wrote:
Btw, how do we POST non-x86 (eg. ppc) video boards? I don't think that
there's x86 code in their ROM...
Same way X does - x86emu
I think he meant using OpenFirmware video cards on x86 boxes. Does
x86emu take care of that? In any case,
I asked this at OLS and no one knew of an open source x86 Open Firmware
emulator.
99% of the time it is people wanting to use cheap x86 cards in Open
Firmware systems to avoid having to pay $$ for those added valued ROMs.
--- Ian Romanick [EMAIL PROTECTED] wrote:
Alan Cox wrote:
On Mer,
