[Kde-hardware-devel] KDE's libsolid

[Pascal Fleury]

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 <pascal at telefleuries.com>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 <ervin at kde.org> 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 kde-hardware-devel at kde.org 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20120902/6564b2c1/attachment.html>