On Mon, Jan 24, 2011 at 1:40 PM, Chris Bagwell <[email protected]> wrote: > I've thought about this patch some more and I wanted to say up front I > think original patch is good to submit. This applies even if you make > minor modification to prefer HW over table values. Both ways: > > Reviewed-by: Chris Bagwell <[email protected]>
I merged the two patches into one so people can see the whole picture in one piece. I added your Reviewed-by tag there. Let me know if you have more questions about the patch. Thank you. > But I do have some longer term questions below. My answer is inline. > On Mon, Jan 24, 2011 at 3:01 PM, Ping Cheng <[email protected]> wrote: >> On Mon, Jan 24, 2011 at 7:49 AM, Chris Bagwell <[email protected]> wrote: >>> Hi Ping, >>> >>> I'm trying to catch up with you in understanding... You mentioned >>> elsewhere that HW is reporting physical size in terms of 0.001 of a >>> cm. >> >> Not just elsewhere :). It is also in this patch's commit comments (the >> second line ;). > > Somehow I keep missing that. > >> >>> Assuming thats true (what a crazy unit!), then the HID spec shows >>> how to compute resolution like this: >>> >>> resolution in units per cm = logical_size / (physical_size * 10-3) >>> >>> Would you mind changing your math below to be closer to HID spec? I >>> think it will help readers understand faster if they've read HID spec >>> first. So I mean change like this: >>> >>> resolution in units per meter = logical_size / (physical_size * 0.1) >> >> I got questions for using this type of forms at linux-input ;). > > I do retract that comment now. I'm preferring your way in fact.. > Somehow I need the fact its 0.001 of cm posted in about 5 different > locations and then perhaps I'll stop getting caught up in math. > >> >>> It would be cool if HID turns out to be reporting in terms of mm >>> (10^-1 or 0.1 of cm). Then it reduces to: >>> >>> resolution in units per meter = logical_size / physical_size >>> >>> I have one more comment below. >>> >>> On Mon, Jan 24, 2011 at 1:39 AM, Ping Cheng <[email protected]> wrote: >>>> resolution = logical size / physical size >>>> >>>> The touch physical size we get from the kernel is in thousandth cm. >>>> The resolution unit we need to report to XInput is in point/m. So, >>>> >>>> touch resolution = logical size * 10 / physical size >>>> >>>> Signed-off-by: Ping Cheng <[email protected]> >>>> --- >>>> src/wcmUSB.c | 24 ++++++++++-------------- >>>> 1 files changed, 10 insertions(+), 14 deletions(-) >>>> >>>> diff --git a/src/wcmUSB.c b/src/wcmUSB.c >>>> index cfaf920..d8e8312 100644 >>>> --- a/src/wcmUSB.c >>>> +++ b/src/wcmUSB.c >>>> @@ -483,33 +483,29 @@ int usbWcmGetRanges(InputInfoPtr pInfo) >>>> common->wcmMaxTouchY = absinfo.maximum; >>>> >>>> /* max finger strip X for tablets with Expresskeys >>>> - * or touch physical X for TabletPCs with touch */ >>>> + * or physical X for touch device in thousandth cm */ >>>> if (ioctl(pInfo->fd, EVIOCGABS(ABS_RX), &absinfo) == 0) >>>> { >>>> - if (is_touch) >>>> - common->wcmTouchResolX = absinfo.maximum; >>>> + if (is_touch && !common->wcmTouchResolX) >>>> + common->wcmTouchResolX = >>>> + (int)(((double)common->wcmMaxTouchX * 10.0 >>>> + / (double)absinfo.maximum) + 0.5); >>> >>> This gives preference to the lookup table instead of hardware. Maybe >>> we should give preference to HW reported value (and fall back to >>> table)? >> >> Good point. I'll think about it a bit more. The issue isn't as simple >> as just a HW reported v.s. a table. >> >> We are dealing with three cases: non-touch devices; touch devices with >> resolution reported through RX/RY for kernels older than 2.6.35; and >> resolution supported by the new EVIOC. >> >> For non-touch devices, the resolution is per-model based. Each product >> ID has a predefined resolution which we can not retrieve from HID. >> That's why we had the table. If we want to get the resolution for >> those devices from the kernel, we would need to move the table to the >> kernel driver. > > Thanks for mentioning that. It was a question I had for you on my > brain queue but hadn't gotten around to asking if HID supported > reporting it for stylus part. I want to eventually submit a kernel > patch to add resolutions for the stylus devices as well and sounds > like it will have to still be a hard code instead of getting from HID. Right. It is hardcoded since we can not retrieve them from HID. Ping ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
