Hi, it is my first bug report so thanks for Your hard work. I have got 2 problems with elographics driver: First: there are options MinX, MaxX and MinY, MaxY that driver uses for caibration process (see convert function) In my opinion xorg used them for pointer in other way. When I put in xorg.conf MinX=424 and MinY=524 then I can use 1/4 Display only. I put 424 and 524 values direct in xf86Elo.c and now I can use entire Display region. Is it name options conflict? Maybe we should rename MinX, MaxX and MinY, MaxY option names used for calibration to MinCalibX, MaxCalibX and MinCalibY, MaxCalibY names? Another problem - there are other bugs in driver code: Before convertion pointer position touchscreen reports cur_x and cur_y values. Then convert function uses MinX, MaxX, MinY and MaxY to convert touchscreen position to display position (return x and y position). After that Motion function shoud update pointer position with x and y values (but in driver code there is cur_x and cur_y without change) It doesn't work ok, so I corrent them to x and y and now the driver works ok. Can You check it and correct ? best regards iu1j4 p.s. I can send You corrected driver code.
(In reply to comment #0) > p.s. I can send You corrected driver code. Yes, please attach your fixes as a patch to this bugreport.
Created attachment 13208 [details] this corrections works ok (but I didn't resolve MinX and MinY options problem) The changes I made in driver works ok with my elographics touchscreen. Try it out. regards
(In reply to comment #1) > (In reply to comment #0) > > p.s. I can send You corrected driver code. > > Yes, please attach your fixes as a patch to this bugreport. > by mistake I add entire driver file, sorry. I checked MinX option name - the problem is not with name of the option but something with structure: EloPrivatePtr it is possible, that: priv->max_x, priv->min_x, priv->max_y, priv->min_y are used for other than callibration process reasons? How could I fix it?
(In reply to comment #3) > by mistake I add entire driver file, sorry. don't worry. just do a diff of your changes and re-upload. bugzilla allows you to mark old attachments as deprecated.
Created attachment 13209 [details] [review] patch for the driver (not complete) Remember, that it didn't resolve MinX and MinY problem
Created attachment 13210 [details] [review] one more correction with width calculation I fond one more place where I should replace min_x and min_y with real values
(In reply to comment #6) > Created an attachment (id=13210) [details] > one more correction with width calculation > > I fond one more place where I should replace min_x and min_y with real values > can you please upload a patch generated with diff -U? it is a lot easier to read. If you are working from the current git version of the driver, just do a git diff > mypatch and then upload this file. Otherwise I think it's diff -U8 original_file modified_file
Created attachment 13214 [details] [review] diff -U 5 patch You are welcome
(In reply to comment #8) > Created an attachment (id=13214) [details] > diff -U 5 patch > > You are welcome thanks. I had a look at it (i don't own such a device so that's all I can do). I agree with the second half of your patch (replacing curr_x with x, etc.). The first half of the patch is just papering over the real issue though. For some reason min_x/min_y is not set correctly. This should be done in xf86EloInit and looks correct to me. Maybe you can debug this and figure out why it forgets the value? (if that's what it does) Also make sure you check your xorg.conf, maybe there's a typo? The driver is generally in a pretty horrible state and officially unmaintained. Feel free to step up and clean it up. I generally recommend getting the git version and going from there. have a look at http://wiki.x.org/wiki/ModularDevelopersGuide to get started.
(In reply to comment #9) > thanks. I had a look at it (i don't own such a device so that's all I can do). > I agree with the second half of your patch (replacing curr_x with x, etc.). > > The first half of the patch is just papering over the real issue though. For > some reason min_x/min_y is not set correctly. This should be done in > xf86EloInit and looks correct to me. Maybe you can debug this and figure out > why it forgets the value? (if that's what it does) Ok, I added some fprintf to find what is wrong and the results: 1. I back to use priv->min_x and priv->min_y again from xorg.conf 2. I print out to stderr the values of priv->min_x and priv->min_y in xf86EloInit 3. I print out to stderr cur_x and cur_x, min_x and min_y, converted x and converted y every pointer motion. Ad. 2) the values of min_x and min_y are the same to compare with xorg.conf Ad. 2) the values of min_x and min_y are the same .. .no changes the values of cur_x and cur_y are correct the values of x and y that are used by xf86PostMotionEvent are correct What is wrong? If the driver run xf86PostMotionEvent(local->dev, TRUE, 0, 2, 18, 6) then it move pointer to priv->min_x , priv->min_y. If new x position of pointer is less than min_x then real PostMotionEvent moves pointer to min_x. The same with min_y. An example: Before xf86PostMotionEvent() (I touch display on left upper corner) curx=452, cury=3557 minx=394, miny=480 newx=18, newy=6 minx and miny are the same in xorg.conf newx and newy are used by PostMotionEvent(x and y variables) the result of PostMotionEvent is to set up the position of pointer in 1/4 right and down of display. If I touch 1/4 right and down then the pointer is setup correctly. I have no idea what can I check more? > Also make sure you check your xorg.conf, maybe there's a typo? It is ok > The driver is generally in a pretty horrible state and officially unmaintained. > Feel free to step up and clean it up. I generally recommend getting the git > version and going from there have a look at > http://wiki.x.org/wiki/ModularDevelopersGuide to get started. > ok, but I will have touchscreen up to 6th january 2008 have you got any idea how to check xf86PostMotionEvent()? Even if I put direct values x=0 and y=0 to it, then I get position of 1/4 right down of display. How could it be possible? If I change MinX and MinY options to 0 in xorg.conf then I get position in left upper corner. best regards iu1j4
(In reply to comment #10) I'm sorry to say that you hit on bug #10324. what happens is the following: the driver sets up the valuator axes with the given min/max values (xf86EloControl, search for InitValuatorAxisStruct) when you post a motion event, the server will clip the axes to these values. So if you specified 500 as a min_x, X will clip any smaller value to 500. Likewise, if you post an event greater than max_x it will scale back. this is not a bug in the driver, it's a problem of the new input code. the only way to get around that for now is to map coordinates yourself. the best way to do so is to init the valuators with -1 as min/max. then you perform all the min/max value mapping in the driver. so say 500/500 is the smallest value the device gives you, you have to make sure that this maps to 0/0 when you post it. X won't do any clipping then and the device should work as intended.
(In reply to comment #11) > (In reply to comment #10) > I'm sorry to say that you hit on bug #10324. what happens is the following: > the driver sets up the valuator axes with the given min/max values > (xf86EloControl, search for InitValuatorAxisStruct) thanks, that is it :) > the only way to get around that for now is to map coordinates yourself. the > best way to do so is to init the valuators with -1 as min/max. then you perform > all the min/max value mapping in the driver. it works :) > so say 500/500 is the smallest value the device gives you, you have to make > sure that this maps to 0/0 when you post it. X won't do any clipping then and > the device should work as intended. and it works thanks again, could You apply the patch into git tree? best regards iu1j4
Created attachment 13248 [details] [review] final patch that works Thanks for help, I hope You will apply this patch and include into xorg
Pushed as 0e04b7142a04fa5e4af57a8056c6010ba49c1359 and 79a2199b8c753aeca6cc9cbbf69e568558a61853.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.