Hi all, I have started playing with this. I have added device types, and added all the interfaces and stubs that are needed. Now I face an issue, when trying to implement the udev backend.
The devices I would like to detect seem to be detectable solely by having a white list of said devices. Generally, they will register properly as a HDI usb device, and udev will make them available as /dev/input/eventX or so. In the udev backend of solid, I would need something that I can depend on to be sure that the device is actually a jog dial (and not another type of hdi input device). for this I did not find a satisfactory solution: 1. have udev rules mount it under a particular /dev/jogdial/deviceX path, that I could detect. It seems brittle to me to do it that way though. 2. have solid itself have access to a DB of vendor/product ID numbers, and switch based on that. The list of such Ids could be kept in sync with the udev rules (most probably by generating files from a common list). That seems a bit at odds with the solid design though. 3. have solid report every HDI device (currently it does not even report mice I think) and let the external library filter the devices based on the white list. I thought I could let udev set some custom properties in the udev rules, but I did not find a way to make it work. Do I miss something obvious ? On Thu, May 31, 2012 at 10:03 PM, Pascal Fleury <[email protected]>wrote: > Hello, > > As pointed out by Kevin, I ask for further information on this mailing > list. > > I was wanting to add better support for Jog/Shuttle devices (input devices > like this one <http://retail.contourdesign.com/?/products/23> that I own) > and was considering adding this as a new type of device to KDE's Solid > library, to increase support across many programs that may use them. Here > is my proposal: > > 1. Add a new device type and Interface to the Solid frontend. This would > let Solid notify about such a device being plugged in, and give some > information about it (#buttons, jog resolution, shuttle min/max values, > product name and device name). > 2. Add a new udevdevice so that the USB device can be detected at least on > Linux. I know too little about other OSs that Solid runs on. > > As pointed out by Kevin, actually listening to events and dealing with > input from the device's interaction would be done externally to Solid. > > Is such a proposal something you would consider at all ? Also, I have no > creds in submitting code to KDE, I have submitted improvements on the > support of such devices to Kdenlive. > > In case you think it's worth it, how/where would information be stored > about the devices themselves? As it turns out, one can only know that it is > a JogShuttle device from the USB VendorID and ProductID, and I guess there > is no means to get the device to tell us about its capabilities, so that it > would have to be stored in some kind of profile database that would have > the info about #buttons, ranges of jog and shuttle etc. > > Thanks for your time, > --Pascal > > On Thu, May 31, 2012 at 10:18 AM, Kevin Ottens <[email protected]> wrote: > >> Hello, >> >> On Wednesday 30 May 2012 02:05:27 you wrote: >> > I was trying to figure out how solid actually works, and I must say I >> was >> > in for a ride.. I think I got it more or less, but have some general >> > questions, if you don't mind. If you have some overview (I've seen the >> dot >> > article and the XMI file in the source tree) I-d love to know about it. >> >> Apart from what you've already seen, there's: >> http://techbase.kde.org/Development/Tutorials/Solid/Introduction >> >> But for the internals the XMI file and the code are pretty much it. >> >> > I was looking if there would be a way to ad a new device type, namely >> > JogShuttle devices (the things used to jog around video content, useful >> for >> > video editing). I thought that the Solid library would actually be able >> to >> > detect that such a device has been plugged into the computer (typically >> > USB), then give some info about it (model name, number of buttons, >> shuttle >> > max values) and finally provide an interface that would let me listen to >> > events from that device concerning the jog/shuttle/buttons. >> >> Note that the last part which requires talking to the device is generally >> not >> covered by libsolid. It's about detecting devices but not about accessing >> them. At most libsolid gives you the necessary bits of information to >> pass to >> a library talking to the actual device. >> >> > It looks however that detecting a new device would be Solid's job. >> >> Yes. >> >> > My >> > question here is how it would detect that it's actually a HogShuttle, as >> > the only way I know to do that would be a list of known >> VendorID/ProductID. >> > Giving some data from the device would also depend on that same set of >> IDs. >> > It is likely that thenumber of buttons on the device does not change >> during >> > operation... >> >> With the partial info I have here I'd say you're after two things: >> * extending the frontend API for your new device type; >> * extending the UDev backend so that it reports those. >> >> > For the last one, an API giving events for operations on the device >> seems >> > to be outside of the scope of Solid (which looks unfortunate to me). >> > >> > Is actually Solid the right place to add support for detecting and >> > listening to such devices ? >> >> Detecting yes, listening no. >> >> > Ialso noticed there was no mouse device listen, >> > nor joysticks. Is it because their support is already ubiquitous there >> is >> > no need for another API for them ? >> >> That, and it's a conscious decision to leave the "talking to the devices" >> part >> out of the API. >> >> BTW, I stepped down as maintainer for libsolid, it's now Alex Fiestas >> duty. >> Also you probably want to email [email protected] that's where >> the >> decision taking for libsolid happens nowadays. >> >> Regards. >> -- >> Kévin Ottens, http://ervin.ipsquad.net >> >> KDAB - proud patron of KDE, http://www.kdab.com >> > >
_______________________________________________ Kde-hardware-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-hardware-devel
