What Do You Want In Linux Drivers This Year?

[djtm]

Better Video Support: 3D Speed, 2D/XRENDER Speed, VDPAU, CUDA, Multi-Head
by the way: I'd also love:
Better Sound Support: Ease and Comfort of Configuration, Quality and Depth of Support
Better WebCam Support: Better support across different applications.
Better Wireless Support: Less Problems with Firmware Retrieval
USB: My devices don't power off in standby -> higher standby watts -> $$

[Wyatt]

Many things everywhere

Oh god, where do I start? With the kernel, logically.

-Sandboxing for inserted kernel modules to allow for more elegant failure

-Improve kernel relocation and to let more users switch running kernels without a restart

-kexec still seems to have some issues. Especially with ACPI.

Power Management:
-Improve ACPI. KMS might help, as a lot of the problems currently seem tied up in graphics hardware, but it couldn't hurt to make other improvements
-more-elegant DSDT error handling
-Add drivers for more hardware ACPI interfaces (Fn key support, etc).
===I've currently under my care multiple laptops that I've no clue at all how the ACPI is actually working on them. I'll figure it out eventually, but it's very mysterious anyway.===
-CONFIG_PM_TRACE for x86_64

-Finish porting to the MAC80211 stack and improve its integration; remove IEEE80211

Device Drivers:
-Improve SATA/PATA mode priority selection and compatability. I'm tired of laptops that allow this to continue to be a pesky issue.
-A driver for Intel's "TurboMemory" NAND flash device would be make it a useful fast swap space. It might also serve as a more convenient scratch space for ACPI debugging than the RTC's NVRAM?
-KMS/GEM Memory Manager integration
-- Caveat: Guarantee that the kernel can elegantly handle a fault in the driver. nvidia.ko and fglrx.ko currently cause oops and panic conditions, which I find mildly unacceptable, though perhaps understandable. Moving things into the kernel should allow for a better solution, I would think.
-Pull OSS4 into the kernel and deprecate ALSA
--alternatively, I hear one of the BSDs has something similar
-Improve USB HID support. Allow for easier writing of gadgets to interface with the device drivers. I have heard at length about the pains that this can cause.
===There exists a device known as "The VT Conroller" that needs to be supported by the current xpad.ko so I may gain first-hand experience in this field in the future.===

Filesystem improvements:
-Rework/extend VFS to support a pure-metadata filesystem. Sort of a chicken and egg problem, it seems.
-Merge Reiser4 into the testing tree to spur growth and positive peer review (It's almost done; BTRFS is a year out at least and I find Ext4 poor about byte conservation).
-Improve the performance of FUSE
-Modernize network filesystem access(? My exposure in this area is minimal because the userspace tools seem very unintuitive. It's fairly unlikely to be a kernel issue, but may as well include it, no?).
-Improved support of ACLs in extended filesystem attributes (Ah MS...you make an amazing fine-grain permissions model and then never bother to use it. Classic)

Proprietary graphics:
-Improve power management. The modern GPU draws more power than the modern CPU in some cases. While this may be unavoidable, not having any means to reduce that in low-load situations is clearly not and you are playing catch-up.
-Bring parity to features and performance
-Note the new features of the kernel an use them. You likely have fewer than eight weeks until kernel 2.6.29: resting on your laurels is a poor choice for garnering support.
-XRandR support would be nice in the non-Xinerama, multi-screen modes (TwinView, I'm looking at you).
--Is DDC/CI auto-rotation supported by any of these drivers?
-nVidia: Performance in this 6600 is an order of magnitude better with noveau than the 180.x series. Frequent updates are nice, but bother to do regression testing.
-AMD: Does fglrx.ko still call on symbols that have been removed from the kernel? If so, fix that; I'd like to update that kernel. If not, thank you; ensure it continues to not be the case.
-VIA: I'm sure your Chrome driver is magical. Maybe it could use some of that mysterious power to appear before us and work as advertised?

Other:
-X.org: evdev could use more robust detection and setup. This seven-button mouse still needs to be manually configured with xorg.conf.
===Isn't the xorg.conf dying? What happened to that plan?===
-DRI: Unify and improve your userland documentation so people will be better-able to choose their driver.

Why do I always end up making my first post too long to read all the way through? Some day I'll learn...

[klikklak]

I forgot 3d vision or the ati version (z3d or whatever it was), either would be really sweet and definitely worth an upgrade.

[jonwil]

I want to see open source support for TV out and hardware MPEG decoding in cards I can buy right now. Dont care if it comes from ATI, Nvidia or wnatever else. All I want is a standalone PCI express video card that I can buy right now that can do TV out and hardware MPEG deciding in open source drivers.

[Vighy]

I want to see open source support for TV out and hardware MPEG decoding in cards I can buy right now. Dont care if it comes from ATI, Nvidia or wnatever else. All I want is a standalone PCI express video card that I can buy right now that can do TV out and hardware MPEG deciding in open source drivers.

Ok, now you can go to bed, and dream about it
Today, you won't see anything of this in opensource.

Maybe in the next months, on ATi cadrs it will happen (once they port the new code to the radeon driver, which I'm sure has working tv-out support based on atombios.
Then it will need at least Gallium3D onto which (still to be developed) can happen the decoding of video contents on the GPU.

I think it will be the first solution in time that will make you able to do what you asked.

[curaga]

I thought many V4L DVB cards, such as ones from Hauppauge, were supported both for tv-out and hardware mpeg? The mpeg decoding should be usable with streams not coming from their own inputs too..