Bug 253672 - Restrict the device list of the UDev backend to only "interesting" devices
Summary: Restrict the device list of the UDev backend to only "interesting" devices
Alias: None
Product: solid
Classification: Unclassified
Component: libsolid-udev (show other bugs)
Version: unspecified
Platform: Unlisted Binaries Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Alex Fiestas
Keywords: release_blocker
Depends on:
Reported: 2010-10-09 16:00 UTC by Kevin Ottens
Modified: 2010-12-07 20:49 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Ottens 2010-10-09 16:00:41 UTC
Right now the UDev backend reports everything udev itself reports. We need to make this list much shorter containing only the devices we actually have some support for (exposing a device interface).
Comment 1 Rafael Fernández López 2010-10-15 12:32:37 UTC
SVN commit 1186190 by ereslibre:

Add support for listing only those changes that are of interest. Not closing the bug since I need to find out how to really list all devices in which we are interested for the UDev backend

CCBUG: 253672

 M  +17 -2     udevmanager.cpp  

WebSVN link: http://websvn.kde.org/?view=rev&revision=1186190
Comment 2 Rafael Fernández López 2010-11-10 02:34:06 UTC
The "interesting" type of devices are

- GenericInterface
- Processor
- Camera
- PortableMediaPlayer

only ? I don't know if also we have to implement in UDev:

- AudioInterface
- Video
Comment 3 Kevin Ottens 2010-11-10 07:32:46 UTC
Video if possible would be nice to have as well. AudioInterface I'm doubtful we can make it from the UDev backend, it'll likely ask for an ALSA one.

That's why I didn't put any of those as blocking bug reports, but if you feel you can make them happen in the UDev backend, by all mean do it. :-)
Comment 4 Rick Stockton 2010-11-11 00:47:44 UTC
Kevin, Rafael: I am only a KDE user and can't read code competently. (And this comment is also *NOT* relevant to the current 4.7 "release_blocker" effort.). Future question:
Does the use of a qt "wrapper" for UDev properties keep KDE trapped in qt's implementation of mouse pointing devices, or can Solid discover extra mouse buttons directly from UDev and it's X11 rules? That could let KDE escape from the long-standing trap that "qt only lets us see 3 mouse buttons".

It already causes considerable unhappiness. (I personally overload KWin with Compiz, because Compiz lets me use my buttons without translating them into keycode sequences.) But I see a near-term future in which "X11 Desktop Computer Users" sit on the couch in front of their 3D, quad-HD televisions -- and they're waving their hands in the air, clicking "buttons" on soft, egg-sized pointer devices in each palm. If we remain stuck with 2 fingers, instead of 5, we're not going to win friends.

I see that qt has recently added gestures with the same old 3-button limitation :(

The folks at qt "could" add support for more sophisticated pointer devices, ... but they could have done it years ago, and and never bit the bullet on expanding the mouse-state byte to provide room for more buttons. Besides, phone screens will probably never distinguish more than two touches doing a "pinch" or "unpinch", so they probably have no Nokia-related strategic interest in supporting multi-button X11 mice. Could KDE support such mice (and future pointers) via Solid, instead of depending on the primitive level of support provided by qt?

Do feel COMPLETELY free to tell me I'm an idiot, and to go away- because, as far as computers go, that's completely true.