On Tue, Nov 3, 2009 at 3:13 PM, Peter Hutterer <span dir="ltr">&lt;<a href="mailto:peter.hutterer@who-t.net">peter.hutterer@who-t.net</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">On Tue, Nov 03, 2009 at 02:42:03PM -0800, Greg KH wrote:<br>
&gt; On Tue, Nov 03, 2009 at 02:35:04PM -0800, Ping wrote:<br>
&gt; &gt; On Tue, Nov 3, 2009 at 2:08 PM, Greg KH &lt;<a href="mailto:greg@kroah.com">greg@kroah.com</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; &gt; On Tue, Nov 03, 2009 at 12:19:54PM -0800, Ping wrote:<br>
&gt; &gt; &gt; &gt; These questions make me feel the kernel driver may need some work.<br>
&gt; &gt; &gt;  Anyway,<br>
&gt; &gt; &gt; &gt; let me share what I have now before we can figure out a better solution:<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Wacom supports both penabled and touch digitizers.  The older tablets<br>
&gt; &gt; &gt; &gt; doesn&#39;t have touch.  So, there is no problem there.  The newer tablets<br>
&gt; &gt; &gt; have<br>
&gt; &gt; &gt; &gt; both pen and touch through the same physical USB port. They are definded<br>
&gt; &gt; &gt; in<br>
&gt; &gt; &gt; &gt; separate HID descriptors with the same vendor id and product id.  So, for<br>
&gt; &gt; &gt; &gt; kernel, I think, it is one physical device.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Yes, but it should show up as 2 different hid devices, right?<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Will that help?  Wacom devices are not processed by HID.  We told hid-core.c<br>
&gt; &gt; to ignore all Wacom devices. That is why I said &quot;I am in control&quot; (I know I<br>
&gt; &gt; am not in control. I am most likely in the middle of nowhere :).<br>
&gt;<br>
&gt; Heh, ah, that makes more sense now.<br>
&gt;<br>
&gt; So you need to intrepret the hid report yourself in your driver and<br>
&gt; export 2 devices to userspace which your xorg driver should then be able<br>
&gt; to determine which is which by some type of identifier in them (not the<br>
&gt; interface number, use the type of the device somehow.)<br>
<br>
</div></div>On that note - if you&#39;re exporting two devices to userspace for this feature<br>
how much more work would it be to have it export the other tools as separate<br>
devices as well. Getting rid of the &quot;one device is really four devices&quot;<br>
seems to be a winner from the X perspective at least. It would slim down the<br>
driver by a great deal.<br></blockquote><div><br>Splitting touch from the other tools may be an option in the kernel. But it will introduce other work in the X driver, such as, we will need to link them together in X driver since we need to disable touch when pen tools are in proximity, etc. The reality is they are actually one physical device, like it or not.  Translating other pen tools into individual devices would bring more work than &quot;bundle&quot; them together, I think. So, I don&#39;t think there would be an easy way for X driver to deal with the device on an one-to-one or one-to-many basis.  It is just a matter of where we are going to put the effort in.<br>
<br>Making one device into many (stylus/eraser/cursor) is an open source feature - users get the freedom to make one physical device into many different types.  Window and Mac can not or do not do this.  From what I understood/learnt, kernel driver reports the raw data as close as it can be.  It is up to the X driver to interpret the data whatever/however the way users or the developers want.  <br>
 <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
It also means we don&#39;t need this massive table in the X driver that decides<br>
which tools are available for a given device - stuff like that belongs in<br>
the kernel driver.<br></blockquote><div><br>One way or the other, somewhere we still need to decide which types the device support. <br><br>So, I am more inclined to stay as is, which causes less rework and keeps the interfaces unchanged.  <br>
<br>Ping<br><br><br></div></div>