Less then 4k lines![]()
Less then 4k lines![]()
Is there a reason we don't have KMS for VESA?
It's already functional on at least one card. When I finished the project, I had a working framebuffer on a Permedia 3.
The next things to do (I had a TODO list somewhere. Can't find it now) are
- i2c/ddc (currently the driver is hard coded to a 1024x768 resolution)
- TTM (only has enough TTM support to allocate the framebuffer)
- support for Permedia 2, 2V, and 4 cards
- update xf86-video-glint to work with KMS
There were some other things on the TODO list, but I can't remember them.
All the docs I have for Permedia cards are here: http://mattst88.com/permedia/
Because that doesn't make any sense.
Could you expand a little on that? I'm curious too. For older cards, you end up running vesa on the kernel, and vesa/fbdev on Xorg, but they normally will have different resolutions and tty switching will be slow, and you don't get kernel panics visible, etc.
Wouldn't getting KMS for VESA solve this?
I thought the issue with KMS VESA was that it would require running video bios code (real mode x86) in the kernel, which is problematic at best and probably forbidden. Presumably the code could be run on a sandboxed x86 emulator, but not sure if that would be enough to give an acceptable level of robustness.
vesa requires real mode bios calls to set modes (plus you are limited to the vesa mode numbers exposed by the bios which do not always match a monitor's native mode) which is not allowed in the kernel. We already have uvesafb which is a vesa kernel fb driver and it has to call into userspace helpers to set modes so it starts to turn into a mess. With native drivers for most hardware already, it doesn't really gain you much for the amount of work required. Plus vesa/vbe goes away with EFI (real mode vbe calls are not allowed with secure boot), replaced by a native EFI GOP driver. There is already an efifb kernel fb driver for the EFI framebuffers, and native drivers for most modern hardware. A KMS driver for GOP is not really an option because once the OS loads, the GOP driver is gone and you can't change the video mode so you are stuck with what the GOP driver set until you load a native driver.
Thank you, that was very informative.
Indeed, thanks for clearing that up.
Yeah, don't ask me why I stated that r100-r200 was dropped from Mesa. I was wrong, and admitting that hurts a little
I am mostly hoping that someone (possibly me if I'm feeling adventurous) can update the 3dfx mesa/kernel drivers to DRI2/kms so that the cards can at least continue to be used with their existing capabilities.
I was asking about Gallium+Alpha partially because I could drop a PCI GeForce 8400 or higher (or the radeon equivalent) in that machine if I was feeling like actually extending the life of that machine. At the moment, my PCI stockpile just consists of Trident, Matrox Millenium, and 3dfx Voodoo 3's, but I've got a GF8400 GS in a HTPC I'm building for my brother-in-law that I could test with for the next few weeks.