[Desktop_architects] raw notes from drivers 12/01/2005 meeting

Christopher Blizzard blizzard at redhat.com
Fri Dec 2 11:06:59 PST 2005


IHV
  quality
  existence

Centralized driver model is the key to user experience

Networking

o Really a wireless problem
o NDIS is a bad idea - legal barrier
o Missing driver
o Wildly inconsistent
o Encryption / Auth
o UI problems still exist and drive kernel requirements
o expose capability through drivers of various 
o software radios are illegal in some areas

Printing

o good thing is that there's a lot of postscript printers - come with a
ppd so they work well
o ppd files - some manufacturers release as open source
o would be nice if everyone did so so the printers worked out of the box
o sometimes the ppd files need some specialization
o passwords in ppd files? rico as an example - linux specific
o secure printing
o easy download for additional drivers
o non-postscript printers? need a special driver for a specific driver
o PCL only needs a little work to implement?
o proprietary protocols require cooperation from the manufacturer
o ijs interface?  ghostscript drivers?  vector drivers don't have an
interface yet
o i18n in ppd files - covered in cups 1.2
o 70% of the market has drivers available based on market share?
o dell is labeling printer from other brand - usually a lexmark and
that's bad
o HP is the best

o PPD files don't support enough for authentication?  for adobe?
  o PPD files aren't extensible enough?
o Who is involved? Adobe owns the spec
o PPD drives features? Needs followup - needs to characterize the
problem because it's not clear here

o detection
o USB vendor and product ID is bad because epson is always the same
answer
o have to use the IEEE 1284 device ID string can get from the printer
with an I/O ctl
o backchannel from the printer to cups and back to the user is missing
entirely
o mike sweet has promised this for cups 1.2!
o cups is for enterprise development, not desktop-driven. missing
features
o once a week developer releases - in mandriva
o back channel is not documented?  not sure if it's there
o simple apis should not be used by the desktop? use more complex apis?

Modem

o drivers for winmodems?
o big patent problem
o license from patent holder? consortium says jrb
ACTION: o nomachine?  check with them because they've probably worked on
this

Video

o one problem is that our driver model is inadequite in X
o on the fly configuration
o devices have to be dynamic
o driver model is broken and has to be replaced?
o lack of specs
o kernel vs. X? x.org slides
o staff and communication between kernel and X
o PCI, blocking vertical retrace, egbert thinks it's solvable
o we need help!
o resource control (multiple graphics cards share common resources like
VGA?)
o kernel drive and 3D driver that needs the resources
o shared memory allocator that's shared with the kenel, 3d and others
o compositing manager is important
o hot plugability - need interface for this
o plugability is a driver problem
o communicate between X and the kernel and some user space app
o proprietary drivers need a single place to install and a single driver
interface
o how to build the drivers and install them
o running two monitors is hard or video is hard
o as much open source as possible
o closed source only where there's an IP issue
- mode setting doesn't have to be closed source!
- 70% should be open source - closed source only where there's IP
o modular X - closed source releases with open source driver releases?
o register parameters are cross-card?
o DKMS kernel installation methods

Monitors

o monitors are hard to detect?
o intel chips don't include monitor control chips
o internal display on laptops are hard
o fixed list of modes on intel chips
o intel could twist arms in this area
o most drivers can't poll once the X server is running!
o on intel you have to do a VT switch!

o UE - add a second monitor is flawless
o X into HAL/Dbus
o and input devices need help here
o kernel is helping here - actually hiding the issues - static
configuration
o anything other than mice is bad

Audio

o 3 categories
o some devices have _no_ drivers: IP issues
o 25% to 40% of devices
o USB drivers have "quirks" - most do work now, though
o headsets aren't supported at all
o UE - need to have a good way of describing them
o Firewire audio is huge in the pro sector
- bridgeco has user space driver - works well but totally not user
friendly
- mostly works with everything - class-level driver
o no kernel driver for firewire audio?
o freebob staying in user space
o lacking a standardized mixing system!
o core alsa guys hope to have hardware mixer problem solved in the next
6 months? unlikely, but it could happen
o consumer vs. pro audio world : hardware mixer abstraction hopefully...
o apps can target alsa directly?
o lots of cards don't have a hardware mixer? more and more -
o sound server, then?
o real audio server - drivers need to be unified by some user space
piece
o do you lie about mixer control?  not clear
o don't design around audiophile, probably
o talk about it over some beers!
o Main problem: no way to impose core audio - no shared vision about
what it should look like.
o leon thinks we're being blind about mass :)
o dmix works for most everything but not 10%
o most apps don't care about just playing a sound
o jim says "no matter what machine they are running on"
o biggest problem: no shared vision - everyone is using the same library

o resources hasn't been available to solve the architecture problem
o look at the history on the mac and windows
  o learn from what they have done or not done
o key is to get all of the parties (KDE/GNOME/mplayer/xine) to agree on
how audio is supposed to work
o goal is that you can say "there's one way to do it."

Scanner / Fax

o faxes - two types
- modems
- multi-function printers
- HP lip project?
- all the others don't care
- no device where it works today
- lots of vendors don't care
- how do we approach these vendors?  need data to bring to them
- tiwanese are they the OEM? they will not do drivers for 
- via and sis make their own chips - hard to get information from these
companies - might be a cultural issue
- sane is for the wrong market
- plug and play doesn't exist for this stuff
- lots of reverse engineering going on here
- need HAL integration here
- HP has working multi-function stuff - very strange!

Cameras

- mass storage, mostly
- need user space work?
- lots of cameras have a shared model for stuff we want to do
- mass driver storage in the kernel has a huge blacklist because lots of
stuff is busted
- even though it's bad it works better than the other stuff on this
list!  
- RAW/DRM - going to be a larger problem in the long term

PDA

- huge inhibitor for desktop deployment in companies
- no shared vision (NSAV)
- hardware is often supported, no software bits
- mostly in user space, not so much drivers
- what about palm desktop for linux?  probably not big enough

Bluetooth
Firewire
Input Devices
Biometric

Docking Stations

- same problem as power mgmt
- need lots of plug and play work

Suspend / Resume
Power Management

pat rochelle summit?

o ACPI is fundamentally broken - can't parse the same as windows
o incomplete driver support means suspend usually works, but unsuspend
doesn't
o can't re-post to the video driver in a lot of cases especially on
laptops
o need X driver support
o fund a summit
o IHV guys - 
o video card maufacturer?
o reduce power for individual devices - right now we waste a huge amount
of power

OUTPUT

o Collaboration is important
o Resources are a huge problem
o Getting people to pay attention is hard because there's no biz case
  o Have to show real numbers - revenue source right now
  o biz intelligence from the community
  o working hardware vs. non-hardware
  o distros need to participate to feed data to the larger community
  o chipset vendors can help drive this
o OSDL might help with a top down approach because they might be able to
twist arms
  o HP and Dell in consumer space
  o IBM in companies
o Drivers is largely a problem of documentation, not a culture problem -
specs are the key
  o relationships are the key - because sometimes things aren't
documented and only the impl reveals the right way to make a device work
o Issues communicating with the kernel community - need very specific
problems - don't present a solution
o IHVs are the big issue - don't believe they have the market share
o lots of devices don't have _any_ documentation!
o contacts are important
o have to describe the value proposition
o sometimes the windows driver source is the only source for how some
hardware works.





More information about the Desktop_architects mailing list