Hi all,<div><br></div><div>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.</div><div><br>
</div><div>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. </div>
<div><br></div><div>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:</div>
<div><br></div><div>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.</div><div>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.</div>
<div>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.</div><div><br></div><div>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. </div>
<div><br></div><div>Do I miss something obvious ? </div><div><br></div><div><br><br><div class="gmail_quote">On Thu, May 31, 2012 at 10:03 PM, Pascal Fleury <span dir="ltr"><<a href="mailto:pascal@telefleuries.com" target="_blank">pascal@telefleuries.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<div><br></div><div>As pointed out by Kevin, I ask for further information on this mailing list.</div><div><br></div>
<div>I was wanting to add better support for Jog/Shuttle devices (input devices like <a href="http://retail.contourdesign.com/?/products/23" target="_blank">this one</a> 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:</div>
<div><br></div><div>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).</div>
<div>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.</div><div><br></div><div>As pointed out by Kevin, actually listening to events and dealing with input from the device's interaction would be done externally to Solid.</div>
<div><br></div><div>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.</div><div><br></div>
<div>
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.</div>
<div><br></div><div>Thanks for your time,</div><div>--Pascal<br><br><div class="gmail_quote"><div class="im">On Thu, May 31, <a href="tel:2012" value="+9722012" target="_blank">2012</a> at 10:18 AM, Kevin Ottens <span dir="ltr"><<a href="mailto:ervin@kde.org" target="_blank">ervin@kde.org</a>></span> wrote:<br>
</div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<div><br>
On Wednesday 30 May <a href="tel:2012" value="+9722012" target="_blank">2012</a> 02:05:27 you wrote:<br>
> I was trying to figure out how solid actually works, and I must say I was<br>
> in for a ride.. I think I got it more or less, but have some general<br>
> questions, if you don't mind. If you have some overview (I've seen the dot<br>
> article and the XMI file in the source tree) I-d love to know about it.<br>
<br>
</div>Apart from what you've already seen, there's:<br>
<a href="http://techbase.kde.org/Development/Tutorials/Solid/Introduction" target="_blank">http://techbase.kde.org/Development/Tutorials/Solid/Introduction</a><br>
<br>
But for the internals the XMI file and the code are pretty much it.<br>
<div><br>
> I was looking if there would be a way to ad a new device type, namely<br>
> JogShuttle devices (the things used to jog around video content, useful for<br>
> video editing). I thought that the Solid library would actually be able to<br>
> detect that such a device has been plugged into the computer (typically<br>
> USB), then give some info about it (model name, number of buttons, shuttle<br>
> max values) and finally provide an interface that would let me listen to<br>
> events from that device concerning the jog/shuttle/buttons.<br>
<br>
</div>Note that the last part which requires talking to the device is generally not<br>
covered by libsolid. It's about detecting devices but not about accessing<br>
them. At most libsolid gives you the necessary bits of information to pass to<br>
a library talking to the actual device.<br>
<div><br>
> It looks however that detecting a new device would be Solid's job.<br>
<br>
</div>Yes.<br>
<div><br>
> My<br>
> question here is how it would detect that it's actually a HogShuttle, as<br>
> the only way I know to do that would be a list of known VendorID/ProductID.<br>
> Giving some data from the device would also depend on that same set of IDs.<br>
> It is likely that thenumber of buttons on the device does not change during<br>
> operation...<br>
<br>
</div>With the partial info I have here I'd say you're after two things:<br>
* extending the frontend API for your new device type;<br>
* extending the UDev backend so that it reports those.<br>
<div><br>
> For the last one, an API giving events for operations on the device seems<br>
> to be outside of the scope of Solid (which looks unfortunate to me).<br>
><br>
> Is actually Solid the right place to add support for detecting and<br>
> listening to such devices ?<br>
<br>
</div>Detecting yes, listening no.<br>
<div><br>
> Ialso noticed there was no mouse device listen,<br>
> nor joysticks. Is it because their support is already ubiquitous there is<br>
> no need for another API for them ?<br>
<br>
</div>That, and it's a conscious decision to leave the "talking to the devices" part<br>
out of the API.<br>
<br>
BTW, I stepped down as maintainer for libsolid, it's now Alex Fiestas duty.<br>
Also you probably want to email <a href="mailto:kde-hardware-devel@kde.org" target="_blank">kde-hardware-devel@kde.org</a> that's where the<br>
decision taking for libsolid happens nowadays.<br>
<br>
Regards.<br>
<span><font color="#888888">--<br>
Kévin Ottens, <a href="http://ervin.ipsquad.net" target="_blank">http://ervin.ipsquad.net</a><br>
<br>
KDAB - proud patron of KDE, <a href="http://www.kdab.com" target="_blank">http://www.kdab.com</a><br>
</font></span></blockquote></div></div></div><br></div>
</blockquote></div><br></div>