Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1583736 > unrolled thread
| Started by | Dmitry Torokhov <dmitry.torokhov@gmail.com> |
|---|---|
| First post | 2017-02-17 21:50 +0100 |
| Last post | 2017-02-21 12:10 +0100 |
| Articles | 20 on this page of 60 — 8 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-02-17 21:50 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Sebastian Reichel <sre@kernel.org> - 2017-02-18 04:30 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-18 12:40 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Sebastian Reichel <sre@kernel.org> - 2017-02-19 00:50 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-19 13:10 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Sebastian Reichel <sre@kernel.org> - 2017-02-19 21:20 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-20 18:00 +0100
Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Andreas Kemnade <andreas@kemnade.info> - 2017-02-18 09:20 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-18 10:20 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-18 12:40 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-18 19:10 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-18 20:30 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-19 00:00 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-19 13:10 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-19 15:20 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-19 18:10 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-19 18:20 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-19 19:00 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-19 20:10 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-19 20:40 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-19 22:00 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-19 23:10 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-19 23:30 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-20 18:00 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-20 20:30 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-20 21:30 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Petr Cvek <petr.cvek@tul.cz> - 2017-02-20 23:30 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-21 09:40 +0100
Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Andreas Kemnade <andreas@kemnade.info> - 2017-02-19 23:40 +0100
Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-19 23:50 +0100
Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-20 18:00 +0100
Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-20 20:40 +0100
Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-20 21:30 +0100
Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-20 22:00 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-18 12:40 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-02-20 02:20 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-20 18:00 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pali Rohár <pali.rohar@gmail.com> - 2017-02-20 20:50 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-20 21:40 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pali Rohár <pali.rohar@gmail.com> - 2017-02-20 22:10 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-20 22:30 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pali Rohár <pali.rohar@gmail.com> - 2017-02-20 23:00 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-21 07:50 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pali Rohár <pali.rohar@gmail.com> - 2017-02-21 10:00 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pali Rohár <pali.rohar@gmail.com> - 2017-02-20 22:10 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-20 22:30 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-02-20 23:00 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-02-20 23:30 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-21 08:00 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Petr Cvek <petr.cvek@tul.cz> - 2017-02-20 23:40 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pali Rohár <pali.rohar@gmail.com> - 2017-02-20 23:50 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-21 07:40 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pali Rohár <pali.rohar@gmail.com> - 2017-02-21 10:10 +0100
Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Andreas Kemnade <andreas@kemnade.info> - 2017-02-21 18:20 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pali Rohár <pali.rohar@gmail.com> - 2017-02-20 23:10 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-21 08:00 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-21 08:20 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pali Rohár <pali.rohar@gmail.com> - 2017-02-21 09:50 +0100
Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Christ van Willegen <cvwillegen@gmail.com> - 2017-02-21 10:00 +0100
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-21 12:10 +0100
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
| From | Pavel Machek <pavel@ucw.cz> |
|---|---|
| Date | 2017-02-19 22:00 +0100 |
| Message-ID | <tcGKl-3F5-9@gated-at.bofh.it> |
| In reply to | #1584241 |
[Multipart message — attachments visible in raw view] — view raw
Hi! > But as said I don't think we need float or fixed point for practical systems > at all. So you are going to loose precision. And if userspace decides to calibrate it slightly differently from kernel, lost precision will matter. > >>> and floating point in kernel is hard. Also > >>> you'd either have to invent new interface, or you'd break touchscreen > >>> for people that already have their touchscreens calibrated. > >> > >> No, I don't break calibration for people using a different chip. > > > > So you propose your touchscreen to behave differently from all other > > touchscreens in tree? > > No. I only propose that my touch screen behaves properly and in the > best way it can. If others are worse, they should also be improved at > some time. Different from all other drivers. Read: broken. No. You have to design interface such that they _can_ be improved, and what you propose does not work that way. > And note that I am not making things different from others in tree, I > am making the tsc2007 right (incl. following the touchscreen bindings > which define the touchscreen size in "Pixels"). Your touch screen is not in any way special, so it has to behave in the same way others do. > > That's just no-go. > > In other words: you want to block any improvements unless your favourite > touchscreen is giving directions... Yes. I want to prevent you from pushing crap into the kernel. If you want to improve it in reasonable way, you know what to do. > >> You seem to repeat yourself and just say which solution you prefer, > >> but I am missing the arguments why your solution (Pass calibration data > >> to userland) is right and the best one. > >> Which problems does it solve? > > > > All you described. > > I think you are missing one problem: providing already properly scaled touch > values to user space. I'm not. Userspace has to know how to do the calibration _anyway_ (for other hardware), so giving scaled values to userspace is useless. > >> How can you implement it in > >> a stable and portable way? > > > > Easily. > > Please go ahead and show code. You don't get to tell me what to do, unless you pay me. You want to break kernel, you do coding. Or pay someone else, preferably someone who knows how to design kernel code. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[toc] | [prev] | [next] | [standalone]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2017-02-19 23:10 +0100 |
| Subject | Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation |
| Message-ID | <tcHQ5-4wZ-13@gated-at.bofh.it> |
| In reply to | #1584256 |
[Multipart message — attachments visible in raw view] — view raw
Hi Pavel, > Am 19.02.2017 um 21:57 schrieb Pavel Machek <pavel@ucw.cz>: > > Hi! > > >> But as said I don't think we need float or fixed point for practical systems >> at all. > > So you are going to loose precision. And if userspace decides to > calibrate it slightly differently from kernel, lost precision will > matter. Really? Example: ADC values go 100 .. 3995 (i.e. touch margin is 100 steps in pre-calibration) This is scaled to let's say 0..640. Now you find your touch is misaligned by 1% which is 6.4 pixels but barely noticeable on a 5cm screen (1% is 0.5mm). So you simply subtract 6 from all coordinates and the screen is aligned again. Does the 0.4 pixel deviation in precision (= 0.2mm) matter? If you do this scaling from ADC range 0..4095 to 0..640 in user-space, you will find that you have to subtract 59 from the ADC values and then scale by 0.16431. The result will be almost the same and deviate in the micrometer range. How big is your stylus or finger? We learn: a real world touch screen is not a high precision instrument. > >>>>> and floating point in kernel is hard. Also >>>>> you'd either have to invent new interface, or you'd break touchscreen >>>>> for people that already have their touchscreens calibrated. >>>> >>>> No, I don't break calibration for people using a different chip. >>> >>> So you propose your touchscreen to behave differently from all other >>> touchscreens in tree? >> >> No. I only propose that my touch screen behaves properly and in the >> best way it can. If others are worse, they should also be improved at >> some time. > > Different from all other drivers. Read: broken. If something differs from requirements or a spec, then it is broken. Not if it differs from other drivers (implementations). They may be broken as well or follow different requirements. Note: 1. the touch screen bindings do ask to scale to screen size (please read http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt ) 2. if you don't use these features the driver behaves exactly as it was before by using defaults and like other drivers which do (not yet) have it > > No. You have to design interface such that they _can_ be improved, and > what you propose does not work that way. It works. Please do real world tests... > >> And note that I am not making things different from others in tree, I >> am making the tsc2007 right (incl. following the touchscreen bindings >> which define the touchscreen size in "Pixels"). > > Your touch screen is not in any way special, so it has to behave in > the same way others do. It does. Plus some new features which are missing... > >>> That's just no-go. >> >> In other words: you want to block any improvements unless your favourite >> touchscreen is giving directions... > > Yes. I want to prevent you from pushing crap into the kernel. Crap? Well, we have discussed this driver for months here on the list and after a lot of improvements we came up to v9. And you still think it is crap and none of the other reviewers has noticed? > > If you want to improve it in reasonable way, you know what to do. > >>>> You seem to repeat yourself and just say which solution you prefer, >>>> but I am missing the arguments why your solution (Pass calibration data >>>> to userland) is right and the best one. >>>> Which problems does it solve? >>> >>> All you described. >> >> I think you are missing one problem: providing already properly scaled touch >> values to user space. > > I'm not. You are. Because you said: "All you described." And I had described that as well. So you were either wrong before or now. > Userspace has to know how to do the calibration _anyway_ (for > other hardware), What for? I do not understand which other hardware you are talking about. On our devices there is only one touch glued to the panel and that one has to be calibrated. Ideally before the user gets the device into his hands => precalibration... If you connect a digitizer, then that one has to be calibrated of course, but it is not glued onto the display panel. Hence it is a different issue. Please describe the use case / scenario you are thinking of. > so giving scaled values to userspace is useless. This is another example why I love to discuss with you :) You are so wonderful in ignoring my explanations during the past 20 mails where I described exactly and in detail why it is useful for me, for others, for users of the GTA04 for the upcoming Pyra device... So at least 2000 or more persons. One daily user of these devices and kernel contributor already had commented his view. IMHO, only Pavel Machek is thinking it is useless. Therefore he concludes it must be useless for everybody else as well. > >>>> How can you implement it in >>>> a stable and portable way? >>> >>> Easily. >> >> Please go ahead and show code. > > You don't get to tell me what to do, unless you pay me. Same for me. But: you get our contributions for free. Unpaid work, we did put into developing these patches for the benefit of mankind. > > You want to break kernel, you do coding. Or pay someone else, > preferably someone who knows how to design kernel code. Ah, so that's the way the wind is blowing... You are trying to block community contributions to get a paid job by pretending to do it better :) This is a quite clever attempt to ruin the open source, volunteer and community idea. It is defined as "building from and giving back to the community". We could easily run our own fork of Linux and ignore upstreaming, but I believe that we should give back something to those who have developed the other parts of Linux we simply use. And you want to exclude us from this? Nonono. It is really funny to discuss with you and I can still learn how to work around really answering questions, accepting that other people have different requirements and ignoring technical arguments and answers given to form a big picture. So just derailing this discussion because you want to be paid is not at all fair. But I can withstand this. Please give me convincing technical arguments (which include our requirements and not only yours) like other reviewers do and we will change code. BR and thanks, Nikolaus
[toc] | [prev] | [next] | [standalone]
| From | Pavel Machek <pavel@ucw.cz> |
|---|---|
| Date | 2017-02-19 23:30 +0100 |
| Message-ID | <tcI9s-4DY-9@gated-at.bofh.it> |
| In reply to | #1584265 |
[Multipart message — attachments visible in raw view] — view raw
hi! > >> But as said I don't think we need float or fixed point for practical systems > >> at all. > > > > So you are going to loose precision. And if userspace decides to > > calibrate it slightly differently from kernel, lost precision will > > matter. > > Really? Really. > Example: > > ADC values go 100 .. 3995 (i.e. touch margin is 100 steps in pre-calibration) > > This is scaled to let's say 0..640. Ok. Now userspace realizes that kernel alignemnt is off, and it would want to scale it to 1..642. That will mean that single pixel will be inaccessible, right? > > No. You have to design interface such that they _can_ be improved, and > > what you propose does not work that way. > > It works. Please do real world tests... You do a real world test on N900, and propose upgrade path. > > Yes. I want to prevent you from pushing crap into the kernel. > > Crap? Well, we have discussed this driver for months here on the list and > after a lot of improvements we came up to v9. > > And you still think it is crap and none of the other reviewers has noticed? I'm pretty sure you will not be able to push calibration into kernel. > > Userspace has to know how to do the calibration _anyway_ (for > > other hardware), > > What for? I do not understand which other hardware you are talking about. > > On our devices there is only one touch glued to the panel and that one > has to be calibrated. Ideally before the user gets the device into his > hands => precalibration... > > If you connect a digitizer, then that one has to be calibrated of course, > but it is not glued onto the display panel. Hence it is a different > issue. It is actually same issue. One kernel interface should work for all the touchscreens. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[toc] | [prev] | [next] | [standalone]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2017-02-20 18:00 +0100 |
| Subject | Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation |
| Message-ID | <tcZtF-7aS-39@gated-at.bofh.it> |
| In reply to | #1584268 |
[Multipart message — attachments visible in raw view] — view raw
Hi Pavel, > Am 19.02.2017 um 23:19 schrieb Pavel Machek <pavel@ucw.cz>: > > hi! > >>>> But as said I don't think we need float or fixed point for practical systems >>>> at all. >>> >>> So you are going to loose precision. And if userspace decides to >>> calibrate it slightly differently from kernel, lost precision will >>> matter. >> >> Really? > > Really. > >> Example: >> >> ADC values go 100 .. 3995 (i.e. touch margin is 100 steps in pre-calibration) >> >> This is scaled to let's say 0..640. > > Ok. Now userspace realizes that kernel alignemnt is off, and it would > want to scale it to 1..642. Screen coordinates are still 0..639. > That will mean that single pixel will be > inaccessible, right? Yes, that can happen if the additional user-space scale is > 1.0. As long as it is small (I expect <1.01 = 1% error in scale) it is barely noticeable. Therefore, I asked before: how big in pixels is your finger or stylus? Does this effect matter? A resistive touch is a man-machine-interface where people press buttons of at least 12x12 pixels size (or they are no longer visually recognizable). A resistive touch is not intended to be a high-precision measurement instrument. So the discussion boils down to "what gives the better usability?": a) getting rid of the nasty user-space calibration step (and plethora of different tools) b) getting highest theoretical precision which has a low practical relevance I am in favor of a). Like most users we ask. A minority is in favor of b). Since we don't exclude b) users from reconfiguring their system to get it done as they like. I think this is the best we can achieve. > >>> No. You have to design interface such that they _can_ be improved, and >>> what you propose does not work that way. >> >> It works. Please do real world tests... > > You do a real world test on N900, and propose upgrade path. I have no N900 running. But since it uses a tsc2004/5 controller which seems to be quite similar, you can likely copy&paste some code or add the algorithm: ABS_X = (touchscreen-size-x * (adc_x - adc_min_x)) / (adc_max_x - adc_min_x) Thats it. If you set touchscreen-size-x = (adc_max_x - adc_min_x) you get maximum precision you can achieve with integer arithmetic. And if you set adc_min_x = 0 your user-space gets what it would have got before adding such a formula and then you can and must do calibration there. Taking this as the defaults if none of the new properties is specified, makes the scaling feature completely disappear. And I don't care about 2 additional subtractions, one multiplication and one division per axis. So the upgrade path is: 1. introduce new optional properties, parse and store them in the struct 2. set defaults for the optional properties as described above 3. add the formula to the code (1 line for each axis) 4. deploy - nobody will notice 5. update the DT and remove user-space calibration - people will be happy that they do not have to calibrate first any more > >>> Yes. I want to prevent you from pushing crap into the kernel. >> >> Crap? Well, we have discussed this driver for months here on the list and >> after a lot of improvements we came up to v9. >> >> And you still think it is crap and none of the other reviewers has noticed? > > I'm pretty sure you will not be able to push calibration into kernel. > >>> Userspace has to know how to do the calibration _anyway_ (for >>> other hardware), >> >> What for? I do not understand which other hardware you are talking about. >> >> On our devices there is only one touch glued to the panel and that one >> has to be calibrated. Ideally before the user gets the device into his >> hands => precalibration... >> >> If you connect a digitizer, then that one has to be calibrated of course, >> but it is not glued onto the display panel. Hence it is a different >> issue. > > It is actually same issue. One kernel interface should work for all > the touchscreens. Do we propose a different kernel interface? We propose to still use input events. There is no change at all here. BR and thanks, Nikolaus
[toc] | [prev] | [next] | [standalone]
| From | Pavel Machek <pavel@ucw.cz> |
|---|---|
| Date | 2017-02-20 20:30 +0100 |
| Message-ID | <td1OO-kv-19@gated-at.bofh.it> |
| In reply to | #1584745 |
[Multipart message — attachments visible in raw view] — view raw
Hi! > As long as it is small (I expect <1.01 = 1% error in scale) it is > barely noticeable. > > Therefore, I asked before: how big in pixels is your finger or stylus? > Does this effect matter? If I draw a line in gimp, I don't expect it to have steps because of "barely noticeable" errors. > A resistive touch is a man-machine-interface where people press buttons of at > least 12x12 pixels size (or they are no longer visually recognizable). Resistive touch is used for drawing, too. > So the discussion boils down to "what gives the better usability?": > a) getting rid of the nasty user-space calibration step (and plethora of different tools) > b) getting highest theoretical precision which has a low practical relevance > > I am in favor of a). Like most users we ask. A minority is in favor of b). > Since we don't exclude b) users from reconfiguring their system to get it done > as they like. I think this is the best we can achieve. Do you even read what I wrote? Because I presented way to have both a) _and_ b). > >>> No. You have to design interface such that they _can_ be improved, and > >>> what you propose does not work that way. > >> > >> It works. Please do real world tests... > > > > You do a real world test on N900, and propose upgrade path. > > I have no N900 running. But since it uses a tsc2004/5 controller which seems > to be quite similar, you can likely copy&paste some code or add the algorithm: > > ABS_X = (touchscreen-size-x * (adc_x - adc_min_x)) / (adc_max_x - adc_min_x) > > Thats it. > > If you set touchscreen-size-x = (adc_max_x - adc_min_x) you get maximum precision > you can achieve with integer arithmetic. And if you set adc_min_x = 0 your > user-space gets what it would have got before adding such a formula and then you > can and must do calibration there. > > Taking this as the defaults if none of the new properties is specified, makes > the scaling feature completely disappear. And I don't care about 2 additional > subtractions, one multiplication and one division per axis. > > So the upgrade path is: > 1. introduce new optional properties, parse and store them in the struct > 2. set defaults for the optional properties as described above > 3. add the formula to the code (1 line for each axis) > 4. deploy - nobody will notice Good so far. > 5. update the DT and remove user-space calibration - people will be happy > that they do not have to calibrate first any more You can't do this. And this is fatal problem with your proposal. If I update the DT in the kernel, my users will be very unhappy, because their screens will now be miscalibrated. New kernel must not force users to update their userland at the same time. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[toc] | [prev] | [next] | [standalone]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2017-02-20 21:30 +0100 |
| Subject | Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation |
| Message-ID | <td2KS-VH-13@gated-at.bofh.it> |
| In reply to | #1584857 |
[Multipart message — attachments visible in raw view] — view raw
HI Pavel, > Am 20.02.2017 um 20:29 schrieb Pavel Machek <pavel@ucw.cz>: > > Hi! > >> As long as it is small (I expect <1.01 = 1% error in scale) it is >> barely noticeable. >> >> Therefore, I asked before: how big in pixels is your finger or stylus? >> Does this effect matter? > > If I draw a line in gimp, I don't expect it to have steps because of > "barely noticeable" errors. You can't draw a line with exactly 1 pixel distance on such a touch screen. > >> A resistive touch is a man-machine-interface where people press buttons of at >> least 12x12 pixels size (or they are no longer visually recognizable). > > Resistive touch is used for drawing, too. Yes, for taking handwritten notes but not for high-precision graphics design. For that you take a bigger screen and zoom the relevant areas. > >> So the discussion boils down to "what gives the better usability?": >> a) getting rid of the nasty user-space calibration step (and plethora of different tools) >> b) getting highest theoretical precision which has a low practical relevance >> >> I am in favor of a). Like most users we ask. A minority is in favor of b). >> Since we don't exclude b) users from reconfiguring their system to get it done >> as they like. I think this is the best we can achieve. > > Do you even read what I wrote? > > Because I presented way to have both a) _and_ b). I am not aware that you did this. You made a proposal for the X system but not for others, e.g. Replicant. > >>>>> No. You have to design interface such that they _can_ be improved, and >>>>> what you propose does not work that way. >>>> >>>> It works. Please do real world tests... >>> >>> You do a real world test on N900, and propose upgrade path. >> >> I have no N900 running. But since it uses a tsc2004/5 controller which seems >> to be quite similar, you can likely copy&paste some code or add the algorithm: >> >> ABS_X = (touchscreen-size-x * (adc_x - adc_min_x)) / (adc_max_x - adc_min_x) >> >> Thats it. >> >> If you set touchscreen-size-x = (adc_max_x - adc_min_x) you get maximum precision >> you can achieve with integer arithmetic. And if you set adc_min_x = 0 your >> user-space gets what it would have got before adding such a formula and then you >> can and must do calibration there. >> >> Taking this as the defaults if none of the new properties is specified, makes >> the scaling feature completely disappear. And I don't care about 2 additional >> subtractions, one multiplication and one division per axis. >> >> So the upgrade path is: >> 1. introduce new optional properties, parse and store them in the struct >> 2. set defaults for the optional properties as described above >> 3. add the formula to the code (1 line for each axis) >> 4. deploy - nobody will notice > > Good so far. Ok! > >> 5. update the DT and remove user-space calibration - people will be happy >> that they do not have to calibrate first any more > > You can't do this. And this is fatal problem with your proposal. > > If I update the DT in the kernel, my users will be very unhappy, > because their screens will now be miscalibrated. If you tell them that they should recalibrate once, after they upgrade to Linux 4.12 because they no longer need it I doubt they will not be very unhappy. And as said I do not expect or force you to take step 5 for the N900 touch screen. Not even step 1. I would take this more sensitive if you would use the same chip. > New kernel must not > force users to update their userland at the same time. Yes, it shouldn't. But to be honest, this is not my experience. I have to tweak userland a little almost every time a new kernel merge window is done. Admittedly not in the input system. And I may be using the wrong distribution. But if you ever want to deploy better features it is really difficult to avoid. Nevertheless, what problem do you have to implement steps 1-4 in kernel and step 5 outside? BR and thanks, Nikolaus
[toc] | [prev] | [next] | [standalone]
| From | Petr Cvek <petr.cvek@tul.cz> |
|---|---|
| Date | 2017-02-20 23:30 +0100 |
| Message-ID | <td4CZ-26B-7@gated-at.bofh.it> |
| In reply to | #1584745 |
Hi Dne 20.2.2017 v 17:50 H. Nikolaus Schaller napsal(a): > Hi Pavel, > >> Am 19.02.2017 um 23:19 schrieb Pavel Machek <pavel@ucw.cz>: >> >> hi! >> >>>>> But as said I don't think we need float or fixed point for practical systems >>>>> at all. >>>> >>>> So you are going to loose precision. And if userspace decides to >>>> calibrate it slightly differently from kernel, lost precision will >>>> matter. >>> >>> Really? >> >> Really. >> >>> Example: >>> >>> ADC values go 100 .. 3995 (i.e. touch margin is 100 steps in pre-calibration) >>> >>> This is scaled to let's say 0..640. >> >> Ok. Now userspace realizes that kernel alignemnt is off, and it would >> want to scale it to 1..642. > > Screen coordinates are still 0..639. > >> That will mean that single pixel will be >> inaccessible, right? > > Yes, that can happen if the additional user-space scale is > 1.0. > > As long as it is small (I expect <1.01 = 1% error in scale) it is > barely noticeable. > > Therefore, I asked before: how big in pixels is your finger or stylus? > Does this effect matter? > > A resistive touch is a man-machine-interface where people press buttons of at > least 12x12 pixels size (or they are no longer visually recognizable). Smallest kernel font is 4x6 (i think) and I'm regularly using 8x8. I would like to be able to select a single letter in the console. cheers, Petr
[toc] | [prev] | [next] | [standalone]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2017-02-21 09:40 +0100 |
| Subject | Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation |
| Message-ID | <tde9k-8uF-5@gated-at.bofh.it> |
| In reply to | #1584939 |
Hi Petr and all, > Am 20.02.2017 um 23:26 schrieb Petr Cvek <petr.cvek@tul.cz>: > > Hi > > Dne 20.2.2017 v 17:50 H. Nikolaus Schaller napsal(a): >> Hi Pavel, >> >>> Am 19.02.2017 um 23:19 schrieb Pavel Machek <pavel@ucw.cz>: >>> >>> hi! >>> >>>>>> But as said I don't think we need float or fixed point for practical systems >>>>>> at all. >>>>> >>>>> So you are going to loose precision. And if userspace decides to >>>>> calibrate it slightly differently from kernel, lost precision will >>>>> matter. >>>> >>>> Really? >>> >>> Really. >>> >>>> Example: >>>> >>>> ADC values go 100 .. 3995 (i.e. touch margin is 100 steps in pre-calibration) >>>> >>>> This is scaled to let's say 0..640. >>> >>> Ok. Now userspace realizes that kernel alignemnt is off, and it would >>> want to scale it to 1..642. >> >> Screen coordinates are still 0..639. >> >>> That will mean that single pixel will be >>> inaccessible, right? >> >> Yes, that can happen if the additional user-space scale is > 1.0. >> >> As long as it is small (I expect <1.01 = 1% error in scale) it is >> barely noticeable. >> >> Therefore, I asked before: how big in pixels is your finger or stylus? >> Does this effect matter? >> >> A resistive touch is a man-machine-interface where people press buttons of at >> least 12x12 pixels size (or they are no longer visually recognizable). > > Smallest kernel font is 4x6 (i think) and I'm regularly using 8x8. I would like > to be able to select a single letter in the console. So you probably have exceptionally good eyes and reading a terminal on a touch screen is not a typical use case (except for us hard-core programmers). Anyways, if there is only a single pixel is not accessible due do rescaling and integer truncation effects (which is what Pavel complained) you can still select single letters in a 4x6 font. --- So, let's close commenting this patch here since in my opinion everything is said and the maintainers have decided not to accept it. I hope that I have not forgotten anyone to answer. Thank you very much to all participants for this discussion, because it was really enlightening to me and contains a lot of new perspectives. BR and thanks, Nikolaus
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kemnade <andreas@kemnade.info> |
|---|---|
| Date | 2017-02-19 23:40 +0100 |
| Subject | Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation |
| Message-ID | <tcIj8-4Ho-25@gated-at.bofh.it> |
| In reply to | #1584256 |
[Multipart message — attachments visible in raw view] — view raw
Hi, On Sun, 19 Feb 2017 21:57:08 +0100 Pavel Machek <pavel@ucw.cz> wrote: > Hi! > > > > But as said I don't think we need float or fixed point for > > practical systems at all. > > So you are going to loose precision. And if userspace decides to > calibrate it slightly differently from kernel, lost precision will > matter. > > > >>> and floating point in kernel is hard. Also > > >>> you'd either have to invent new interface, or you'd break > > >>> touchscreen for people that already have their touchscreens > > >>> calibrated. > > >> > > >> No, I don't break calibration for people using a different chip. > > > > > > So you propose your touchscreen to behave differently from all > > > other touchscreens in tree? > > > > No. I only propose that my touch screen behaves properly and in the > > best way it can. If others are worse, they should also be improved > > at some time. > > Different from all other drivers. Read: broken. > > No. You have to design interface such that they _can_ be improved, and > what you propose does not work that way. > Then the consequent way would be to use i2c directly from userspace. Because maybe for some really, really unusual you can do something better there. Maybe adjust on-chip filtering (here the MAV-filter) to interact better with your userspace filtering or something like that if you want to exactly detect where maybe a mosquito tries to drill into your touch screen (if the pressure would be enough...) > > And note that I am not making things different from others in tree, > > I am making the tsc2007 right (incl. following the touchscreen > > bindings which define the touchscreen size in "Pixels"). > > Your touch screen is not in any way special, so it has to behave in > the same way others do. > I agree, the tsc2007 (=what the interface provides to userspace) should not behave special, for example it should behave like the virtual touchscreen (=what the interface provides to userspace) virtualbox gives. No need to be calibrated. Well, the internals are different. But that is what the kernel is good for, abstract such things. Conclusion: It cannot be totally wrong behavior to have pixel values there. And the generic touchscreen bindings describe the size in "Pixels" as said by Nikolaus, And here it is up to the dt to decide whether the touch screen is good enough in position so it does not need to be manually calibrated or there are chances to improve something. If there is no calibration in the dt, then nothing changes. Regards, Andreas
[toc] | [prev] | [next] | [standalone]
| From | Pavel Machek <pavel@ucw.cz> |
|---|---|
| Date | 2017-02-19 23:50 +0100 |
| Subject | Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation |
| Message-ID | <tcIsN-4KT-3@gated-at.bofh.it> |
| In reply to | #1584271 |
[Multipart message — attachments visible in raw view] — view raw
Hi! > > > And note that I am not making things different from others in tree, > > > I am making the tsc2007 right (incl. following the touchscreen > > > bindings which define the touchscreen size in "Pixels"). > > > > Your touch screen is not in any way special, so it has to behave in > > the same way others do. > > > > I agree, the tsc2007 (=what the interface provides to userspace) should > not behave special, for example it should behave like the virtual > touchscreen (=what the interface provides to userspace) virtualbox > gives. No need to be calibrated. Well, the internals are different. But > that is what the kernel is good for, abstract such things. > Conclusion: It cannot be totally wrong behavior to have pixel values > there. It is not "totally wrong". But it is useless code that should not be in kernel. Calibration certainly does not belong to single _driver_. Feel free to submit driver but keep the calibration code out of tree... But if you have userspace that depends on touchscreen to be calibrated... that _is_ wrong. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[toc] | [prev] | [next] | [standalone]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2017-02-20 18:00 +0100 |
| Subject | Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation |
| Message-ID | <tcZtE-7aS-29@gated-at.bofh.it> |
| In reply to | #1584273 |
[Multipart message — attachments visible in raw view] — view raw
Hi Pavel, > Am 19.02.2017 um 23:39 schrieb Pavel Machek <pavel@ucw.cz>: > > Hi! > >>>> And note that I am not making things different from others in tree, >>>> I am making the tsc2007 right (incl. following the touchscreen >>>> bindings which define the touchscreen size in "Pixels"). >>> >>> Your touch screen is not in any way special, so it has to behave in >>> the same way others do. >>> >> >> I agree, the tsc2007 (=what the interface provides to userspace) should >> not behave special, for example it should behave like the virtual >> touchscreen (=what the interface provides to userspace) virtualbox >> gives. No need to be calibrated. Well, the internals are different. But >> that is what the kernel is good for, abstract such things. >> Conclusion: It cannot be totally wrong behavior to have pixel values >> there. > > It is not "totally wrong". But it is useless code that should not be > in kernel. Calibration certainly does not belong to single > _driver_. It belongs to driver + attached panel. I.e. hardware. Which the kernel or driver should IMHO abstract from as good as possible. > Feel free to submit driver For what? The tsc2007 driver already exists. > but keep the calibration code out > of tree... It is the really important patch to add this. > > But if you have userspace that depends on touchscreen to be > calibrated... that _is_ wrong. User-space people and real users have the opposite opinion. They prefer if a touch is plug&play. I.e. without need for calibration. When did you last time re-calibrate the heads of your hard disk in user-space? BR and thanks, Nikolaus
[toc] | [prev] | [next] | [standalone]
| From | Pavel Machek <pavel@ucw.cz> |
|---|---|
| Date | 2017-02-20 20:40 +0100 |
| Subject | Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation |
| Message-ID | <td1Yt-nS-15@gated-at.bofh.it> |
| In reply to | #1584751 |
[Multipart message — attachments visible in raw view] — view raw
Hi! > > But if you have userspace that depends on touchscreen to be > > calibrated... that _is_ wrong. > > User-space people and real users have the opposite opinion. They > prefer if a touch is plug&play. I.e. without need for calibration. Some people prefer to calibrate their touchscreens; because of per-device variations, that gives better precision. You can pass default calibration data from device tree to kernel to userland. But you can not force people to use that calibration. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[toc] | [prev] | [next] | [standalone]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2017-02-20 21:30 +0100 |
| Subject | Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation |
| Message-ID | <td2KR-VH-1@gated-at.bofh.it> |
| In reply to | #1584861 |
[Multipart message — attachments visible in raw view] — view raw
Hi, > Am 20.02.2017 um 20:32 schrieb Pavel Machek <pavel@ucw.cz>: > > Hi! > >>> But if you have userspace that depends on touchscreen to be >>> calibrated... that _is_ wrong. >> >> User-space people and real users have the opposite opinion. They >> prefer if a touch is plug&play. I.e. without need for calibration. > > Some people prefer to calibrate their touchscreens; because of > per-device variations, that gives better precision. > > You can pass default calibration data from device tree to kernel to > userland. But you can not force people to use that calibration. Yes, you can do that if you want. I hope it became clear by the formula in my last mail. I just want to be able to do it the other way for those users who don't care about this per-device variation. BR, Nikolaus
[toc] | [prev] | [next] | [standalone]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2017-02-20 22:00 +0100 |
| Subject | Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation |
| Message-ID | <td3dU-16y-23@gated-at.bofh.it> |
| In reply to | #1584881 |
[Multipart message — attachments visible in raw view] — view raw
> Am 20.02.2017 um 21:22 schrieb H. Nikolaus Schaller <hns@goldelico.com>: > > Hi, > >> Am 20.02.2017 um 20:32 schrieb Pavel Machek <pavel@ucw.cz>: >> >> Hi! >> >>>> But if you have userspace that depends on touchscreen to be >>>> calibrated... that _is_ wrong. >>> >>> User-space people and real users have the opposite opinion. They >>> prefer if a touch is plug&play. I.e. without need for calibration. >> >> Some people prefer to calibrate their touchscreens; because of >> per-device variations, that gives better precision. >> >> You can pass default calibration data from device tree to kernel to >> userland. But you can not force people to use that calibration. > > Yes, you can do that if you want. I hope it became clear by the formula > in my last mail. Sorry this can be completely misleading, if read in conjunction with your sentences. Brevity in answers may disturb the message. It does not mean that you can and should force people to use that calibration... It means that users still can do per-device calibration and do not have to use the pre-calibration capability of the driver. Hence we called it pre-calibration. > > I just want to be able to do it the other way for those users who don't > care about this per-device variation. > > BR, > Nikolaus > > _______________________________________________ > http://projects.goldelico.com/p/gta04-kernel/ > Letux-kernel mailing list > Letux-kernel@openphoenux.org > http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
[toc] | [prev] | [next] | [standalone]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2017-02-18 12:40 +0100 |
| Subject | Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation |
| Message-ID | <tcbwR-1i3-1@gated-at.bofh.it> |
| In reply to | #1583736 |
Hi Dmitry,
> Am 17.02.2017 um 21:40 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>
> Hi Nikolaus,
>
> On Sat, Jan 28, 2017 at 10:44:35PM +0100, H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>>
>>> Am 28.01.2017 um 20:33 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>>>
>>> Hi Nikolaus,
>>>
>>> On Wed, Dec 28, 2016 at 03:53:16PM +0100, H. Nikolaus Schaller wrote:
>>>> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
>>>> introduced common DT bindings for touchscreens [1] and a helper function to
>>>> parse the DT.
>>>>
>>>> commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
>>>> added another helper for parsing axis inversion and swapping
>>>> and applying them to x and y coordinates.
>>>>
>>>> Both helpers have been integrated to accommodate any orientation of the
>>>> touch panel in relation to the LCD.
>>>>
>>>> A new feature is to introduce scaling the min/max ADC values to the screen
>>>> size.
>>>>
>>>> This makes it possible to pre-calibrate the touch so that is (almost)
>>>> exactly matches the LCD pixel coordinates it is glued onto. This allows to
>>>> well enough operate the touch before a user space calibration step can
>>>> improve the precision.
>>>
>>> I question whether doing scaling in kernel is really right solution.
>>
>> Since lower left corner does not exactly report [0 0] and upper right corner
>> does not report [4095 4095] from the ADC we need offset and steepness correction
>> of the ADC values.
>>
>> This steepness is the scaling that must happen in kernel and I don't understand
>> why you want to propagate this ADC errors to user-space by avoiding scaling.
>>
>> Let me iterate what we want to achieve:
>> * use new common bindings
>> * offset and steepness calibration of the ADC (called pre-calibration).
>> This makes a real device much more reliable to operate with factory installed
>> scaling factors.
>> * flipping and rotation
>>
>> (note that touch pixel to LCD pixel scaling is not explicitly on this list!)
>
> That was explicitly called out in the patch:
>
> "A new feature is to introduce scaling the min/max ADC values to the
> screen size."
Because it is a feature that was not planned nor required, but is there. So it came
into the description of what can be done. If this is the key problem I am happy with
removing it from the commit messages.
Anyways, scaling to screen coordinates is not my invention. It is based on
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
which defines the size to be in pixels. Well, a resistive touch screen does not have pixels.
It might have a resolution/precision given by the ADC conversion steps but I assume
this is not meant here.
So this scaling to screen size was also stimulated by this DT bindings.
>
>>
>> Now to achieve the ADC pre-calibration we must calculate
>>
>> x' = (x - ti,min-x) / (ti,max-x-ti,min-x) giving a rante from 0.0 ... 1.0
>>
>> This is scaled up to what is defined by touchscreen-size-x, i.e.
>>
>> x' = (touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x)
>>
>> How do you want to avoid this scaling to take place? It happens automatically.
>> It is not even an additional line of code. And is necessary for compensating ADC
>> offsets and steepness.
>>
>> So the only way to avoid the scaling option is to eliminate the precalibration/ADC
>> compensation which is essential for a device which has no means to properly
>> calibrate before operating the device through touch.
>>
>> The other option would be to avoid common bindings and set
>>
>> touchscreen-size-x = (ti,max-x-ti,min-x)
>>
>> This is heavily dependent on specific ADC offsets forwarded to user-space.
>> IMHO the worst we can do (and the current tsc2007 driver does it that way!).
>>
>>>
>>> Why do you want this?
>>
>> It seems that you assume that we want to enforce 1:1 scaling between touch pixels
>> and LCD pixels and have designed code to achieve exactly that.
>>
>> This is not the case. It is just a byproduct that you can do it.
>>
>> And since it is easier to understand we have made the examples this way.
>>
>>> If your touch resolution is lower than your screen
>>> then it might be useful, but if it is lower then you are losing data
>>> that can be very helpful for gesture recognition, and I hope you design
>>> your userspace so it can handle not only "bad" hardware, but "good" as
>>> well. And even with "bad" there are a lot of tricks that can be done to
>>> get "better" touch position in userspace.
>>
>> You can just *choose* DT parameters touchscreen-size-x to match the LCD size.
>> This of course reduces the touch precision to full LCD pixels. For finger-
>> touch operated devices, subpixel precision is rarely needed.
>>
>> Also, some user-spaces (e.g. older Replicant for GTA04) assume that there is
>> such an 1:1 mapping and they will be perfectly happy about this.
>>
>> But, if you can modify your user-space easily, you can also choose a different
>> factor.
>>
>> You can for example define touchscreen-size-x=<4096> and then you get almost
>> the highest precision of the ADC and won't loose any bits. Or even define a
>> bigger range and get steps >1 bit.
>>
>> LCD driver (e.g. X11 calibration matrix) can scale it down again to LCD pixels.
>>
>> So effectively we get for LCD pixels when the touch sets a mouse pointer:
>>
>> x'' = user-space-scale * <<input-event<< ((touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x))
>>
>> The most simple setup would then be but others are possible:
>>
>> user-space-scale = 1
>> touchscreen-size-x = LCD-size-x
>>
>> Let me cite myself:
>>
>>>> This makes it possible to pre-calibrate the touch so that is (almost)
>
> Yes, it allows you to pre-calibrate, I get it. But you still do properly
> calibrate later, right?
No. We want to get rid of this step unless we need to improve the precision by
some tiny %.
Why do we want to get rid of it?
This needs a longer explanation.
First of all we are working on the Letux distribution which aims at supporting
multiple devices in the same way and with a single SD card image that contains
one or multiple rootfs (Debian X11, QtMoko, Replicant etc.) the kernel uImage
and DTB files for each supported device.
One of the ideas is to allow users to swap the SD card from one device to the
other. This means that the touch screen calibration must magically be carried
along - or we enforce to recalibrate every time the sd card is swapped back or
forth.
The same is true for prebuilt SD-images. To have a single (no longer device specific)
download requires to have a well defined default calibration. Especially on
devices where you have no keyboard where you can ask the user to manually fine-tune
something.
Our challenge is to make it work well without asking for explicit calibration.
This is where pre-calibration comes into the game.
It turns out to be related to the touch screen properties and how it is glued onto
the specific LCD panel, i.e. hardware and its description.
So the natural location of defining this relation is the DTB for each device
and not the user-space. And it happens that we already have one per device
(touch screen, lcd, tsc variant) on the SD card.
> So you are doing double work here, once in
> kernel, and second time in userspace.
This is no longer required, as long as we can use the default 1:1 coordinate mapping
of e.g. framebuffer or X11 based GUI toolkits.
If we don't have the 1:1 mapping of touch screen input event coordinates
to LCD pixels we have a mess of different scaling factors back in user-space
again. And the problem is setting them up properly in an installable .tbz
or .dd image.
Recently, you have raised another topic I had indeed not thought abut, which is
the potential subpixel precision of a resistive touch. You get approx. 12
bit from the ADC but the x coordinate of the 480 pixel wide screen is just 9
bit. So scaling the input event coordinates to pixels throws away 3 bits.
But there are two things to consider.
One is that we could set the pre-calibration to keep as much resolution as
possible, ca. 12 pixels and make the user-space scale down to screen coordinates.
Unfortunately that differs between devices and hence we need not only
different DTBs (which we already have) but different scale factors in user-space.
Next, one could argue that subpixel coordinates should not be handled by
scaling input event coordinates up and then down again in user-space. The
correct solution would be that input events could report fixed or floating
point coordinates, but this is probably beyond what we all want to do.
The other thing is noise. No resistive touch screen I have seen in the wild with
the tsc2007 or tsc2046 controller has the precision to really report subpixels.
Rather we have to set the fuzz between 3 or 10 or so. Which means that those
bits we cut off by scaling to screen coordinates are already lost in noise.
>
> I'd be more open to allowing setting the "min-axis" values to allow
> reporting typical range for given device, and let userspace scale as it
> sees fit.
The problem is: what is "typical range"? It turns out to be a completely
arbitrary definition.
I see a choice between:
a) full theoretical ADC range
b) millimeters
c) pixels of the LCD the touch is glued to
For me, the most natural and practical "typical range" still seems to be the
pixels of the lcd panel the touch is glued onto.
The reason why I see it as superior to the others is that only this leads to
a stable 1:1 mapping in user-space avoiding to adjust any factors there.
And this 1:1 saves a lot of configuration hassle if you swap GUI systems
(X, Wayland, Android, DirectFB, fb based Qt, ...).
>
>>
>>>
>>>>
>>>> Please note that the old ti,fuzz properties have been removed since they
>>>> are replaced by the common bindings touchscreen-fuzz-x/y/z.
>>>>
>>>> Finally, calculate_pressure has been renamed to calculate_resistance
>>>> because that is what it is doing.
>>>
>>> That is not what your patch does though. In the presence of
>>> "ti,report-resistance" parameter you start reporting resistance through
>>> ABS_PRESSURE
>>
>> Well, there is some historic confusion wether this driver reports resistance
>> or pressure.
>>
>> The unpatched tsc2007 driver does it wrong (please test!) and we fix it on
>> the fly (because a separate patch is much more complex than doing it right
>> immediately).
>>
>> This ti,report-resistance property is a means to get the old (wrong) meaning back
>> in case someone urgently needs it and can't fix the user-space workaround which
>> he must be using.
>>
>>
>> AFAIK there is no mainline board using the DT except ours (and the upcoming
>> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
>> compatibility property. We don't need it for our devices.
>>
>
> You seem to be treating DT data as something very fluid, which is wrong.
No,only sometimes.
Of course it should be done right once. Of course there is long discussion about
what is right...
> You need to treat it as a firmware, unlikely to change once device is
> shipped. Unlike legacy platform data, the fact that DTS files are not
> present in mainline does not mean that we can ignore such users and
> change behavior at will.
Well, it happens to me as maintainer of a 99.5% mainline device every
now and then. Of course this should not be an argument to do it equally bad here.
One more thought: for some devices it is easier to modify the DTB "firmware"
than the user space (e.g. if you have no access to it because it is maintained
by somebody else).
>
> That said, if driver behavior is out of line from the subsystem
> expectations, we need to fix it.
>
>
>> That the function name is wrong is a second issue and this double negation might
>> confuse a litte.
>>
>> Please test on a real device if the patched driver reports pressure now (unless
>> ti,report-resistance is specified).
>
> I unfortunately can not test this driver as I do not have the hardware.
Ah, ok. This is indeed a road block.
Maybe someone else with a real tsc2007 hardware is reading this discussion and can comment?
> So all my observations are from code and data sheets.
> That said, what is the values emitted as ABS_PRESSURE when finger is not
> touching the device, barely touching the device, or pressing firmly?
> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
> confusion as to what is being reported.
Indeed. The original tsc2007 jumps from 0 to a maximum value and goes down when
pressing more firmly. This is not "pressure". The other drivers (I have tested
the OpenPandora with tsc2046) are doing it in a monotonic curve.
Hence I suggested to fix it for the tsc2007 (any perhaps others showing the same bug).
And allow a mechanism for those people who can more easily touch the DTB file than
the user space to turn it back to the old but wrong situation by setting a DT
property (maybe even in their boot.scr).
> I am adding a few more folks to the CC so we can try and soft this out.
> Sebastian, Pali, Pavel, any input here?
Fine!
BR and thanks,
Nikolaus
[toc] | [prev] | [next] | [standalone]
| From | Dmitry Torokhov <dmitry.torokhov@gmail.com> |
|---|---|
| Date | 2017-02-20 02:20 +0100 |
| Message-ID | <tcKNY-6k2-11@gated-at.bofh.it> |
| In reply to | #1583884 |
Hi Nikolaus,
On Sat, Feb 18, 2017 at 12:32:48PM +0100, H. Nikolaus Schaller wrote:
> Hi Dmitry,
>
> > Am 17.02.2017 um 21:40 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> >
> > Hi Nikolaus,
> >
> > On Sat, Jan 28, 2017 at 10:44:35PM +0100, H. Nikolaus Schaller wrote:
> >> Hi Dmitry,
> >>
> >>> Am 28.01.2017 um 20:33 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> >>>
> >>> Hi Nikolaus,
> >>>
> >>> On Wed, Dec 28, 2016 at 03:53:16PM +0100, H. Nikolaus Schaller wrote:
> >>>> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
> >>>> introduced common DT bindings for touchscreens [1] and a helper function to
> >>>> parse the DT.
> >>>>
> >>>> commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
> >>>> added another helper for parsing axis inversion and swapping
> >>>> and applying them to x and y coordinates.
> >>>>
> >>>> Both helpers have been integrated to accommodate any orientation of the
> >>>> touch panel in relation to the LCD.
> >>>>
> >>>> A new feature is to introduce scaling the min/max ADC values to the screen
> >>>> size.
> >>>>
> >>>> This makes it possible to pre-calibrate the touch so that is (almost)
> >>>> exactly matches the LCD pixel coordinates it is glued onto. This allows to
> >>>> well enough operate the touch before a user space calibration step can
> >>>> improve the precision.
> >>>
> >>> I question whether doing scaling in kernel is really right solution.
> >>
> >> Since lower left corner does not exactly report [0 0] and upper right corner
> >> does not report [4095 4095] from the ADC we need offset and steepness correction
> >> of the ADC values.
> >>
> >> This steepness is the scaling that must happen in kernel and I don't understand
> >> why you want to propagate this ADC errors to user-space by avoiding scaling.
> >>
> >> Let me iterate what we want to achieve:
> >> * use new common bindings
> >> * offset and steepness calibration of the ADC (called pre-calibration).
> >> This makes a real device much more reliable to operate with factory installed
> >> scaling factors.
> >> * flipping and rotation
> >>
> >> (note that touch pixel to LCD pixel scaling is not explicitly on this list!)
> >
> > That was explicitly called out in the patch:
> >
> > "A new feature is to introduce scaling the min/max ADC values to the
> > screen size."
>
> Because it is a feature that was not planned nor required, but is
> there. So it came into the description of what can be done. If this is
> the key problem I am happy with removing it from the commit messages.
>
> Anyways, scaling to screen coordinates is not my invention. It is
> based on
>
> http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>
> which defines the size to be in pixels. Well, a resistive touch screen
> does not have pixels. It might have a resolution/precision given by
> the ADC conversion steps but I assume this is not meant here.
>
> So this scaling to screen size was also stimulated by this DT
> bindings.
>
OK, now I see where you are coming from. You assume that pixels
mentioned in the DT binding are LCD pixels, however this is incorrect.
They are "pixels" or the touch controller, i.e. native unites in which
device reports coordinates, as opposed to points per inch, or
millimeters, or whatever. These "pixels" do not have to have 1:1
relation to the LCD pixels; in fact they rarely do.
Input driver may set resolution for given axis in units per mm (or units
per radian for rotational axis ABS_RX, ABS_RY, ABS_RZ), and if you
check the binding, you can use "touchscreen-x-mm" and "touchscreen-y-mm"
to specify the size of entire touch surface and set resolution from it
so that userspace can calculate the proper scaling factor.
> >
> >>
> >> Now to achieve the ADC pre-calibration we must calculate
> >>
> >> x' = (x - ti,min-x) / (ti,max-x-ti,min-x) giving a rante from 0.0 ... 1.0
> >>
> >> This is scaled up to what is defined by touchscreen-size-x, i.e.
> >>
> >> x' = (touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x)
> >>
> >> How do you want to avoid this scaling to take place? It happens automatically.
> >> It is not even an additional line of code. And is necessary for compensating ADC
> >> offsets and steepness.
> >>
> >> So the only way to avoid the scaling option is to eliminate the precalibration/ADC
> >> compensation which is essential for a device which has no means to properly
> >> calibrate before operating the device through touch.
> >>
> >> The other option would be to avoid common bindings and set
> >>
> >> touchscreen-size-x = (ti,max-x-ti,min-x)
> >>
> >> This is heavily dependent on specific ADC offsets forwarded to user-space.
> >> IMHO the worst we can do (and the current tsc2007 driver does it that way!).
> >>
> >>>
> >>> Why do you want this?
> >>
> >> It seems that you assume that we want to enforce 1:1 scaling between touch pixels
> >> and LCD pixels and have designed code to achieve exactly that.
> >>
> >> This is not the case. It is just a byproduct that you can do it.
> >>
> >> And since it is easier to understand we have made the examples this way.
> >>
> >>> If your touch resolution is lower than your screen
> >>> then it might be useful, but if it is lower then you are losing data
> >>> that can be very helpful for gesture recognition, and I hope you design
> >>> your userspace so it can handle not only "bad" hardware, but "good" as
> >>> well. And even with "bad" there are a lot of tricks that can be done to
> >>> get "better" touch position in userspace.
> >>
> >> You can just *choose* DT parameters touchscreen-size-x to match the LCD size.
> >> This of course reduces the touch precision to full LCD pixels. For finger-
> >> touch operated devices, subpixel precision is rarely needed.
> >>
> >> Also, some user-spaces (e.g. older Replicant for GTA04) assume that there is
> >> such an 1:1 mapping and they will be perfectly happy about this.
> >>
> >> But, if you can modify your user-space easily, you can also choose a different
> >> factor.
> >>
> >> You can for example define touchscreen-size-x=<4096> and then you get almost
> >> the highest precision of the ADC and won't loose any bits. Or even define a
> >> bigger range and get steps >1 bit.
> >>
> >> LCD driver (e.g. X11 calibration matrix) can scale it down again to LCD pixels.
> >>
> >> So effectively we get for LCD pixels when the touch sets a mouse pointer:
> >>
> >> x'' = user-space-scale * <<input-event<< ((touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x))
> >>
> >> The most simple setup would then be but others are possible:
> >>
> >> user-space-scale = 1
> >> touchscreen-size-x = LCD-size-x
> >>
> >> Let me cite myself:
> >>
> >>>> This makes it possible to pre-calibrate the touch so that is (almost)
> >
> > Yes, it allows you to pre-calibrate, I get it. But you still do properly
> > calibrate later, right?
>
> No. We want to get rid of this step unless we need to improve the precision by
> some tiny %.
>
> Why do we want to get rid of it?
>
> This needs a longer explanation.
>
> First of all we are working on the Letux distribution which aims at supporting
> multiple devices in the same way and with a single SD card image that contains
> one or multiple rootfs (Debian X11, QtMoko, Replicant etc.) the kernel uImage
> and DTB files for each supported device.
>
> One of the ideas is to allow users to swap the SD card from one device to the
> other. This means that the touch screen calibration must magically be carried
> along - or we enforce to recalibrate every time the sd card is swapped back or
> forth.
>
> The same is true for prebuilt SD-images. To have a single (no longer device specific)
> download requires to have a well defined default calibration. Especially on
> devices where you have no keyboard where you can ask the user to manually fine-tune
> something.
>
> Our challenge is to make it work well without asking for explicit calibration.
> This is where pre-calibration comes into the game.
>
> It turns out to be related to the touch screen properties and how it is glued onto
> the specific LCD panel, i.e. hardware and its description.
>
> So the natural location of defining this relation is the DTB for each device
> and not the user-space. And it happens that we already have one per device
> (touch screen, lcd, tsc variant) on the SD card.
>
> > So you are doing double work here, once in
> > kernel, and second time in userspace.
>
> This is no longer required, as long as we can use the default 1:1 coordinate mapping
> of e.g. framebuffer or X11 based GUI toolkits.
>
> If we don't have the 1:1 mapping of touch screen input event coordinates
> to LCD pixels we have a mess of different scaling factors back in user-space
> again. And the problem is setting them up properly in an installable .tbz
> or .dd image.
Why? Nothing stops you from querying the device and figure out scaling.
We do that, for example, on Chrome OS, where we do not have 1:1 matching
between LCDs and touch controllers, and still we do not have static
transformation matrices on the file system either.
>
> Recently, you have raised another topic I had indeed not thought abut, which is
> the potential subpixel precision of a resistive touch. You get approx. 12
> bit from the ADC but the x coordinate of the 480 pixel wide screen is just 9
> bit. So scaling the input event coordinates to pixels throws away 3 bits.
>
> But there are two things to consider.
>
> One is that we could set the pre-calibration to keep as much resolution as
> possible, ca. 12 pixels and make the user-space scale down to screen coordinates.
>
> Unfortunately that differs between devices and hence we need not only
> different DTBs (which we already have) but different scale factors in user-space.
>
> Next, one could argue that subpixel coordinates should not be handled by
> scaling input event coordinates up and then down again in user-space. The
> correct solution would be that input events could report fixed or floating
> point coordinates, but this is probably beyond what we all want to do.
>
> The other thing is noise. No resistive touch screen I have seen in the wild with
> the tsc2007 or tsc2046 controller has the precision to really report subpixels.
> Rather we have to set the fuzz between 3 or 10 or so. Which means that those
> bits we cut off by scaling to screen coordinates are already lost in noise.
I really do not care what exactly tsc2007 or any other particular
touchscreen controller does. Please design your software so that it can
use wide range of devices, from noisy to noiseless. If there is noise,
filter it out. It there is a nice touch controller with a lot of
precision - use it, do not dumb it down to the lowest common
denominator.
>
> >
> > I'd be more open to allowing setting the "min-axis" values to allow
> > reporting typical range for given device, and let userspace scale as it
> > sees fit.
>
> The problem is: what is "typical range"? It turns out to be a completely
> arbitrary definition.
>
> I see a choice between:
> a) full theoretical ADC range
> b) millimeters
> c) pixels of the LCD the touch is glued to
d) Native reporting units for the touch controller. You will have the
touch controller output range, you will have your LCD screen size, and
you scale one into another.
>
> For me, the most natural and practical "typical range" still seems to be the
> pixels of the lcd panel the touch is glued onto.
>
> The reason why I see it as superior to the others is that only this leads to
> a stable 1:1 mapping in user-space avoiding to adjust any factors there.
>
> And this 1:1 saves a lot of configuration hassle if you swap GUI systems
> (X, Wayland, Android, DirectFB, fb based Qt, ...).
Yes, they will need to do that, if they want to use "nice" hardware and
not lose precision. And since they need to do that anyway, there is no
point in doing it in kernel, not with per driver code, and not even in
input core.
You are getting this feedback from several people, please consider topic
of adding scaling to the drivers closed. The only transformations that I
think make sense is to "normalize" output with axis swaps and
inversions, so that kernel uses the same notion of coordinates for all
devices, regardless of how the device was mounted.
>
> >
> >>
> >>>
> >>>>
> >>>> Please note that the old ti,fuzz properties have been removed since they
> >>>> are replaced by the common bindings touchscreen-fuzz-x/y/z.
> >>>>
> >>>> Finally, calculate_pressure has been renamed to calculate_resistance
> >>>> because that is what it is doing.
> >>>
> >>> That is not what your patch does though. In the presence of
> >>> "ti,report-resistance" parameter you start reporting resistance through
> >>> ABS_PRESSURE
> >>
> >> Well, there is some historic confusion wether this driver reports resistance
> >> or pressure.
> >>
> >> The unpatched tsc2007 driver does it wrong (please test!) and we fix it on
> >> the fly (because a separate patch is much more complex than doing it right
> >> immediately).
> >>
> >> This ti,report-resistance property is a means to get the old (wrong) meaning back
> >> in case someone urgently needs it and can't fix the user-space workaround which
> >> he must be using.
> >>
> >>
> >> AFAIK there is no mainline board using the DT except ours (and the upcoming
> >> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
> >> compatibility property. We don't need it for our devices.
> >>
> >
> > You seem to be treating DT data as something very fluid, which is wrong.
>
> No,only sometimes.
>
> Of course it should be done right once. Of course there is long discussion about
> what is right...
>
> > You need to treat it as a firmware, unlikely to change once device is
> > shipped. Unlike legacy platform data, the fact that DTS files are not
> > present in mainline does not mean that we can ignore such users and
> > change behavior at will.
>
> Well, it happens to me as maintainer of a 99.5% mainline device every
> now and then. Of course this should not be an argument to do it equally bad here.
>
> One more thought: for some devices it is easier to modify the DTB "firmware"
> than the user space (e.g. if you have no access to it because it is maintained
> by somebody else).
And still, according to DT folks, device tree forms an ABI and thus we
are not to change it, even if it is easy.
>
> >
> > That said, if driver behavior is out of line from the subsystem
> > expectations, we need to fix it.
> >
> >
> >> That the function name is wrong is a second issue and this double negation might
> >> confuse a litte.
> >>
> >> Please test on a real device if the patched driver reports pressure now (unless
> >> ti,report-resistance is specified).
> >
> > I unfortunately can not test this driver as I do not have the hardware.
>
> Ah, ok. This is indeed a road block.
>
> Maybe someone else with a real tsc2007 hardware is reading this discussion and can comment?
>
> > So all my observations are from code and data sheets.
>
> > That said, what is the values emitted as ABS_PRESSURE when finger is not
> > touching the device, barely touching the device, or pressing firmly?
>
> > It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
> > confusion as to what is being reported.
>
> Indeed. The original tsc2007 jumps from 0 to a maximum value and goes down when
> pressing more firmly. This is not "pressure". The other drivers (I have tested
> the OpenPandora with tsc2046) are doing it in a monotonic curve.
OK, then this is clearly wrong and we need to fix it (without any funky
flags).
Thanks.
--
Dmitry
[toc] | [prev] | [next] | [standalone]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2017-02-20 18:00 +0100 |
| Subject | Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation |
| Message-ID | <tcZtG-7aS-63@gated-at.bofh.it> |
| In reply to | #1584301 |
Hi Dmitry,
> Am 20.02.2017 um 02:07 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>
> Hi Nikolaus,
>
> On Sat, Feb 18, 2017 at 12:32:48PM +0100, H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>>
>>> Am 17.02.2017 um 21:40 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>>>
>>> Hi Nikolaus,
>>>
>>> On Sat, Jan 28, 2017 at 10:44:35PM +0100, H. Nikolaus Schaller wrote:
>>>> Hi Dmitry,
>>>>
>>>>> Am 28.01.2017 um 20:33 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>>>>>
>>>>> Hi Nikolaus,
>>>>>
>>>>> On Wed, Dec 28, 2016 at 03:53:16PM +0100, H. Nikolaus Schaller wrote:
>>>>>> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
>>>>>> introduced common DT bindings for touchscreens [1] and a helper function to
>>>>>> parse the DT.
>>>>>>
>>>>>> commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
>>>>>> added another helper for parsing axis inversion and swapping
>>>>>> and applying them to x and y coordinates.
>>>>>>
>>>>>> Both helpers have been integrated to accommodate any orientation of the
>>>>>> touch panel in relation to the LCD.
>>>>>>
>>>>>> A new feature is to introduce scaling the min/max ADC values to the screen
>>>>>> size.
>>>>>>
>>>>>> This makes it possible to pre-calibrate the touch so that is (almost)
>>>>>> exactly matches the LCD pixel coordinates it is glued onto. This allows to
>>>>>> well enough operate the touch before a user space calibration step can
>>>>>> improve the precision.
>>>>>
>>>>> I question whether doing scaling in kernel is really right solution.
>>>>
>>>> Since lower left corner does not exactly report [0 0] and upper right corner
>>>> does not report [4095 4095] from the ADC we need offset and steepness correction
>>>> of the ADC values.
>>>>
>>>> This steepness is the scaling that must happen in kernel and I don't understand
>>>> why you want to propagate this ADC errors to user-space by avoiding scaling.
>>>>
>>>> Let me iterate what we want to achieve:
>>>> * use new common bindings
>>>> * offset and steepness calibration of the ADC (called pre-calibration).
>>>> This makes a real device much more reliable to operate with factory installed
>>>> scaling factors.
>>>> * flipping and rotation
>>>>
>>>> (note that touch pixel to LCD pixel scaling is not explicitly on this list!)
>>>
>>> That was explicitly called out in the patch:
>>>
>>> "A new feature is to introduce scaling the min/max ADC values to the
>>> screen size."
>>
>
>> Because it is a feature that was not planned nor required, but is
>> there. So it came into the description of what can be done. If this is
>> the key problem I am happy with removing it from the commit messages.
>>
>> Anyways, scaling to screen coordinates is not my invention. It is
>> based on
>>
>> http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>>
>> which defines the size to be in pixels. Well, a resistive touch screen
>> does not have pixels. It might have a resolution/precision given by
>> the ADC conversion steps but I assume this is not meant here.
>>
>> So this scaling to screen size was also stimulated by this DT
>> bindings.
>>
>
> OK, now I see where you are coming from. You assume that pixels
> mentioned in the DT binding are LCD pixels,
Yes. Because that makes a lot of sense to me to understand it that way.
> however this is incorrect.
How should I know that, if it is not explicitly defined?
We even had the very same discussion some months ago during v2 or v3,
if I remember correctly. Sebastian raised some concerns about the interpretation
back then but I though that it was clarified and accepted how I interpret
it. At least there were no complaints about it but a lot of valuable comments
to improve the code. So we are now at v9.
> They are "pixels" or the touch controller, i.e. native unites in which
> device reports coordinates, as opposed to points per inch, or
> millimeters, or whatever. These "pixels" do not have to have 1:1
> relation to the LCD pixels; in fact they rarely do.
I wouldn't call this "pixels". Rather "ADC steps" or something.
"Pixels" are picture elements for me and a touch has no picture. It is
an input device. Hence my assumption that it must clearly mean the LCD
pixels it is glued to. And nothing else.
What I don't understand with your definition is why it is in the DT
at all. The driver is 100% tied to a specific chip. So this is a hard
data sheet constant for all tsc2007 chips which can be compiled into
the driver binary. It does not even need to be defined in a DT "firmware".
This was another reason why I though this can not be meant by pixels
in the DT bindings.
And from a theoretical point of view the units are even completely
arbitrary. Loss of precision is only a factor here if you do not have
subpixel reporting to the input layer. But that is an implementation
detail and has nothing to do with the bindings.
Anyways, You can simply set "touchscreen-size = 4096" for your tsc2007
system and you get from the driver the maximum precision it can ever provide.
This is what it did before and what you expect.
So please notice it is not an either or. It is an as well as what we propose.
Defined by the formulae used for scaling.
>
> Input driver may set resolution for given axis in units per mm (or units
> per radian for rotational axis ABS_RX, ABS_RY, ABS_RZ), and if you
> check the binding, you can use "touchscreen-x-mm" and "touchscreen-y-mm"
> to specify the size of entire touch surface and set resolution from it
> so that userspace can calculate the proper scaling factor.
How is this information exposed by the kernel to user-space? By scanning the DT file
or tree?
>
>>>
>>>>
>>>> Now to achieve the ADC pre-calibration we must calculate
>>>>
>>>> x' = (x - ti,min-x) / (ti,max-x-ti,min-x) giving a rante from 0.0 ... 1.0
>>>>
>>>> This is scaled up to what is defined by touchscreen-size-x, i.e.
>>>>
>>>> x' = (touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x)
>>>>
>>>> How do you want to avoid this scaling to take place? It happens automatically.
>>>> It is not even an additional line of code. And is necessary for compensating ADC
>>>> offsets and steepness.
>>>>
>>>> So the only way to avoid the scaling option is to eliminate the precalibration/ADC
>>>> compensation which is essential for a device which has no means to properly
>>>> calibrate before operating the device through touch.
>>>>
>>>> The other option would be to avoid common bindings and set
>>>>
>>>> touchscreen-size-x = (ti,max-x-ti,min-x)
>>>>
>>>> This is heavily dependent on specific ADC offsets forwarded to user-space.
>>>> IMHO the worst we can do (and the current tsc2007 driver does it that way!).
>>>>
>>>>>
>>>>> Why do you want this?
>>>>
>>>> It seems that you assume that we want to enforce 1:1 scaling between touch pixels
>>>> and LCD pixels and have designed code to achieve exactly that.
>>>>
>>>> This is not the case. It is just a byproduct that you can do it.
>>>>
>>>> And since it is easier to understand we have made the examples this way.
>>>>
>>>>> If your touch resolution is lower than your screen
>>>>> then it might be useful, but if it is lower then you are losing data
>>>>> that can be very helpful for gesture recognition, and I hope you design
>>>>> your userspace so it can handle not only "bad" hardware, but "good" as
>>>>> well. And even with "bad" there are a lot of tricks that can be done to
>>>>> get "better" touch position in userspace.
>>>>
>>>> You can just *choose* DT parameters touchscreen-size-x to match the LCD size.
>>>> This of course reduces the touch precision to full LCD pixels. For finger-
>>>> touch operated devices, subpixel precision is rarely needed.
>>>>
>>>> Also, some user-spaces (e.g. older Replicant for GTA04) assume that there is
>>>> such an 1:1 mapping and they will be perfectly happy about this.
>>>>
>>>> But, if you can modify your user-space easily, you can also choose a different
>>>> factor.
>>>>
>>>> You can for example define touchscreen-size-x=<4096> and then you get almost
>>>> the highest precision of the ADC and won't loose any bits. Or even define a
>>>> bigger range and get steps >1 bit.
>>>>
>>>> LCD driver (e.g. X11 calibration matrix) can scale it down again to LCD pixels.
>>>>
>>>> So effectively we get for LCD pixels when the touch sets a mouse pointer:
>>>>
>>>> x'' = user-space-scale * <<input-event<< ((touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x))
>>>>
>>>> The most simple setup would then be but others are possible:
>>>>
>>>> user-space-scale = 1
>>>> touchscreen-size-x = LCD-size-x
>>>>
>>>> Let me cite myself:
>>>>
>>>>>> This makes it possible to pre-calibrate the touch so that is (almost)
>>>
>>> Yes, it allows you to pre-calibrate, I get it. But you still do properly
>>> calibrate later, right?
>>
>> No. We want to get rid of this step unless we need to improve the precision by
>> some tiny %.
>>
>> Why do we want to get rid of it?
>>
>> This needs a longer explanation.
>>
>> First of all we are working on the Letux distribution which aims at supporting
>> multiple devices in the same way and with a single SD card image that contains
>> one or multiple rootfs (Debian X11, QtMoko, Replicant etc.) the kernel uImage
>> and DTB files for each supported device.
>>
>> One of the ideas is to allow users to swap the SD card from one device to the
>> other. This means that the touch screen calibration must magically be carried
>> along - or we enforce to recalibrate every time the sd card is swapped back or
>> forth.
>>
>> The same is true for prebuilt SD-images. To have a single (no longer device specific)
>> download requires to have a well defined default calibration. Especially on
>> devices where you have no keyboard where you can ask the user to manually fine-tune
>> something.
>>
>> Our challenge is to make it work well without asking for explicit calibration.
>> This is where pre-calibration comes into the game.
>>
>> It turns out to be related to the touch screen properties and how it is glued onto
>> the specific LCD panel, i.e. hardware and its description.
>>
>> So the natural location of defining this relation is the DTB for each device
>> and not the user-space. And it happens that we already have one per device
>> (touch screen, lcd, tsc variant) on the SD card.
>>
>>> So you are doing double work here, once in
>>> kernel, and second time in userspace.
>>
>> This is no longer required, as long as we can use the default 1:1 coordinate mapping
>> of e.g. framebuffer or X11 based GUI toolkits.
>>
>> If we don't have the 1:1 mapping of touch screen input event coordinates
>> to LCD pixels we have a mess of different scaling factors back in user-space
>> again. And the problem is setting them up properly in an installable .tbz
>> or .dd image.
>
> Why? Nothing stops you from querying the device and figure out scaling.
What stops me is that I have no (and do not want to have) that level of control over
user-space code.
I can't change Debian, AchLinux, Ubuntu, Replicant, and 100 other systems in parallel
to make the touch work as we want to have it, i.e. precalibrated.
BTW, there is a tendency to point to the kernel to do it right...
> We do that, for example, on Chrome OS, where we do not have 1:1 matching
> between LCDs and touch controllers, and still we do not have static
> transformation matrices on the file system either.
Yes, of course it can be solved that way. We could even go further and develop
a touch screen interface by using /dev/i2c. This avoids having a tsc2007 driver
at all. And all other touch screen drivers can be removed as well. It is all
possible, but IMHO not reasonable for good reasons.
>
>>
>> Recently, you have raised another topic I had indeed not thought abut, which is
>> the potential subpixel precision of a resistive touch. You get approx. 12
>> bit from the ADC but the x coordinate of the 480 pixel wide screen is just 9
>> bit. So scaling the input event coordinates to pixels throws away 3 bits.
>>
>> But there are two things to consider.
>>
>> One is that we could set the pre-calibration to keep as much resolution as
>> possible, ca. 12 pixels and make the user-space scale down to screen coordinates.
>>
>> Unfortunately that differs between devices and hence we need not only
>> different DTBs (which we already have) but different scale factors in user-space.
>>
>> Next, one could argue that subpixel coordinates should not be handled by
>> scaling input event coordinates up and then down again in user-space. The
>> correct solution would be that input events could report fixed or floating
>> point coordinates, but this is probably beyond what we all want to do.
>>
>> The other thing is noise. No resistive touch screen I have seen in the wild with
>> the tsc2007 or tsc2046 controller has the precision to really report subpixels.
>> Rather we have to set the fuzz between 3 or 10 or so. Which means that those
>> bits we cut off by scaling to screen coordinates are already lost in noise.
>
> I really do not care what exactly tsc2007 or any other particular
> touchscreen controller does. Please design your software so that it can
> use wide range of devices, from noisy to noiseless. If there is noise,
> filter it out.
1. noise is an unavoidable physical phenomenon for resistive touch + ADC
2. filtering noise is what the input layer is doing by the fuzz factor. So it is one layer
above the tsc2007 driver.
> It there is a nice touch controller with a lot of
> precision - use it,
I still do not see how this patch influences non-tsc2007 touch controllers.
I explained how the tsc2007 can be used with full precision. Either by providing
a different value for touchscreen-size and recompiling the DTB or by using subpixel
coordinates in input events.
> do not dumb it down to the lowest common
> denominator.
>
>>
>>>
>>> I'd be more open to allowing setting the "min-axis" values to allow
>>> reporting typical range for given device, and let userspace scale as it
>>> sees fit.
>>
>> The problem is: what is "typical range"? It turns out to be a completely
>> arbitrary definition.
>>
>> I see a choice between:
>> a) full theoretical ADC range
>> b) millimeters
>> c) pixels of the LCD the touch is glued to
>
> d) Native reporting units for the touch controller. You will have the
> touch controller output range, you will have your LCD screen size, and
> you scale one into another.
That is exactly what I mean with a) ("full theoretical ADC range" = "touch controller output range"),
so it is not a new alternative.
IMHO c) is the right and natural default.
>
>>
>> For me, the most natural and practical "typical range" still seems to be the
>> pixels of the lcd panel the touch is glued onto.
>>
>> The reason why I see it as superior to the others is that only this leads to
>> a stable 1:1 mapping in user-space avoiding to adjust any factors there.
>>
>> And this 1:1 saves a lot of configuration hassle if you swap GUI systems
>> (X, Wayland, Android, DirectFB, fb based Qt, ...).
>
> Yes, they will need to do that, if they want to use "nice" hardware and
> not lose precision.
This is where I think a proper solution for not loosing precision would be to
introduce subpixel reporting to the input layer.
But in our practical experience with real devices, people complained that the
touch is misaligned. But nobody complained about loss of precision so far. It
came up here as a theoretical discussion in a quite late phase for the first
time.
> And since they need to do that anyway, there is no
> point in doing it in kernel, not with per driver code, and not even in
> input core.
>
> You are getting this feedback from several people,
So far I only know Pavel and you. Which are two.
I also have the feedback of many users of the GTA04 that the pre-calibration and
scaling is really good (when using these patches).
So I wonder what is more important: users or something else?
> please consider topic
> of adding scaling to the drivers closed.
You are of course free to decide this way since you are the maintainer. I just
want to note for the records that you ignore user's wishes. I hope this is not
a general phenomenon.
> The only transformations that I
> think make sense is to "normalize" output with axis swaps and
> inversions, so that kernel uses the same notion of coordinates for all
> devices, regardless of how the device was mounted.
Who will do that?
Do you expect that I submit a version which lacks one feature I think it
is important? And one which is difficult to not implement by accident if you
want to use the common touchscreen bindings?
>
>
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>> Please note that the old ti,fuzz properties have been removed since they
>>>>>> are replaced by the common bindings touchscreen-fuzz-x/y/z.
>>>>>>
>>>>>> Finally, calculate_pressure has been renamed to calculate_resistance
>>>>>> because that is what it is doing.
>>>>>
>>>>> That is not what your patch does though. In the presence of
>>>>> "ti,report-resistance" parameter you start reporting resistance through
>>>>> ABS_PRESSURE
>>>>
>>>> Well, there is some historic confusion wether this driver reports resistance
>>>> or pressure.
>>>>
>>>> The unpatched tsc2007 driver does it wrong (please test!) and we fix it on
>>>> the fly (because a separate patch is much more complex than doing it right
>>>> immediately).
>>>>
>>>> This ti,report-resistance property is a means to get the old (wrong) meaning back
>>>> in case someone urgently needs it and can't fix the user-space workaround which
>>>> he must be using.
>>>>
>>>>
>>>> AFAIK there is no mainline board using the DT except ours (and the upcoming
>>>> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
>>>> compatibility property. We don't need it for our devices.
>>>>
>>>
>>> You seem to be treating DT data as something very fluid, which is wrong.
>>
>> No,only sometimes.
>>
>> Of course it should be done right once. Of course there is long discussion about
>> what is right...
>>
>>> You need to treat it as a firmware, unlikely to change once device is
>>> shipped. Unlike legacy platform data, the fact that DTS files are not
>>> present in mainline does not mean that we can ignore such users and
>>> change behavior at will.
>>
>> Well, it happens to me as maintainer of a 99.5% mainline device every
>> now and then. Of course this should not be an argument to do it equally bad here.
>>
>> One more thought: for some devices it is easier to modify the DTB "firmware"
>> than the user space (e.g. if you have no access to it because it is maintained
>> by somebody else).
>
> And still, according to DT folks, device tree forms an ABI and thus we
> are not to change it, even if it is easy.
I think this needs a more differentiated view.
In my view the names of the binding properties and what they influence form indeed
an ABI. It should be stable and interpreted in the same way.
But it allows to load different firmware for different requirements. Like the user
application ABI is stable but you can still load different software.
So changing the value of a property in a specific .dtb file is a modified firmware
but does not change the ABI. Adding/removing properties is an ABI change.
Here, we are discussing of using different values for touchscreen-size if someone
needs higher precision and wants to do user-space scaling.
This patch neither stops anyone from doing it nor does it require anyone to use
it. Hence we give you the most flexible solution I can think of but there are complaints
because it seems to be too flexible.
So loading a "low resolution but precalibrated" firmware or loading a "high precision
firmware which needs user-space calibration step" does not change ABI.
>>
>>>
>>> That said, if driver behavior is out of line from the subsystem
>>> expectations, we need to fix it.
>>>
>>>
>>>> That the function name is wrong is a second issue and this double negation might
>>>> confuse a litte.
>>>>
>>>> Please test on a real device if the patched driver reports pressure now (unless
>>>> ti,report-resistance is specified).
>>>
>>> I unfortunately can not test this driver as I do not have the hardware.
>>
>> Ah, ok. This is indeed a road block.
>>
>> Maybe someone else with a real tsc2007 hardware is reading this discussion and can comment?
>>
>>> So all my observations are from code and data sheets.
>>
>>> That said, what is the values emitted as ABS_PRESSURE when finger is not
>>> touching the device, barely touching the device, or pressing firmly?
>>
>>> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
>>> confusion as to what is being reported.
>>
>> Indeed. The original tsc2007 jumps from 0 to a maximum value and goes down when
>> pressing more firmly. This is not "pressure". The other drivers (I have tested
>> the OpenPandora with tsc2046) are doing it in a monotonic curve.
>
> OK, then this is clearly wrong and we need to fix it (without any funky
> flags).
I am almost done with a patch series for this as promised to Sebastian.
Comes in some minutes.
BR and thanks,
Nikolaus
[toc] | [prev] | [next] | [standalone]
| From | Pali Rohár <pali.rohar@gmail.com> |
|---|---|
| Date | 2017-02-20 20:50 +0100 |
| Subject | Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation |
| Message-ID | <td28a-rt-17@gated-at.bofh.it> |
| In reply to | #1584757 |
[Multipart message — attachments visible in raw view] — view raw
Hi Nikolaus! On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote: > Hi Dmitry, > > > Input driver may set resolution for given axis in units per mm (or > > units per radian for rotational axis ABS_RX, ABS_RY, ABS_RZ), and > > if you check the binding, you can use "touchscreen-x-mm" and > > "touchscreen-y-mm" to specify the size of entire touch surface and > > set resolution from it so that userspace can calculate the proper > > scaling factor. > > How is this information exposed by the kernel to user-space? By > scanning the DT file or tree? Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS ioctl() on input device. Look at struct input_absinfo, you should have all needed information here. This is generic input interface, no DT is needed. I hope that XServer is already using it for evdev devices... For whole implementation look at evtest program. That should be good starting point for your userspace implementation. While I'm watching this discussion... in my opinion kernel should just invert input axes (when needed) and should not do any other normalization or integer/floating-point re-calibration/re-calculation. If it correctly exports minimum value, maximum value and resolution then userspace can correctly re-scale input events to units which userspace needs (e.g. mapping into LCD screen pixels or whatever is needed). -- Pali Rohár pali.rohar@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2017-02-20 21:40 +0100 |
| Subject | Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation |
| Message-ID | <td2Uy-Zo-7@gated-at.bofh.it> |
| In reply to | #1584864 |
[Multipart message — attachments visible in raw view] — view raw
Hi Pali, > Am 20.02.2017 um 20:42 schrieb Pali Rohár <pali.rohar@gmail.com>: > > Hi Nikolaus! > > On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote: >> Hi Dmitry, >> >>> Input driver may set resolution for given axis in units per mm (or >>> units per radian for rotational axis ABS_RX, ABS_RY, ABS_RZ), and >>> if you check the binding, you can use "touchscreen-x-mm" and >>> "touchscreen-y-mm" to specify the size of entire touch surface and >>> set resolution from it so that userspace can calculate the proper >>> scaling factor. >> >> How is this information exposed by the kernel to user-space? By >> scanning the DT file or tree? > > Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS > ioctl() on input device. Look at struct input_absinfo, you should have > all needed information here. This is generic input interface, no DT is > needed. This assumes that I can and want to write a graphics system myself. > > I hope that XServer is already using it for evdev devices... No idea if it does. It is a black box for me out of our control. > > For whole implementation look at evtest program. That should be good > starting point for your userspace implementation. The problem I have is that *I* have no userspace implementation and the GTA04 project does not want to enforce one. We have several different ones: X11 based (LXDE and others), Qt (fb based), Replicant to name some. All have the same problem to be solved once. The common denominator for a solution are 2 lines of code in the kernel plus some DT properties you need anyways if calibration should be automated in userland. > > While I'm watching this discussion... in my opinion kernel should just > invert input axes (when needed) and should not do any other > normalization or integer/floating-point re-calibration/re-calculation. > If it correctly exports minimum value, maximum value and resolution then > userspace can correctly re-scale input events to units which userspace > needs (e.g. mapping into LCD screen pixels or whatever is needed). It can, but afaik it does not yet. And if it does, it does it in a plethora of different implementation states. That is the reason why we want to solve it once for all userlands in the kernel and not rely on user-space help. Surely, userland can do a lot of things. It could also do the whole file system stuff (FUSE). A more input device related example comes to my mind: userland could do keyboard mapping completely. It would suffice if the kernel presents some x/y coordinates or gpio-numbers for buttons and user-space could map. Still there is a (pre-)mapping to Key-Codes. And yes, they are mapped a second time in userland if needed, but it works sufficiently well if not done. BR and thanks, Nikolaus
[toc] | [prev] | [next] | [standalone]
| From | Pali Rohár <pali.rohar@gmail.com> |
|---|---|
| Date | 2017-02-20 22:10 +0100 |
| Subject | Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation |
| Message-ID | <td3nB-1p5-25@gated-at.bofh.it> |
| In reply to | #1584887 |
[Multipart message — attachments visible in raw view] — view raw
On Monday 20 February 2017 21:35:18 H. Nikolaus Schaller wrote: > Hi Pali, > > > Am 20.02.2017 um 20:42 schrieb Pali Rohár <pali.rohar@gmail.com>: > > > > Hi Nikolaus! > > > > On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote: > >> Hi Dmitry, > >> > >>> Input driver may set resolution for given axis in units per mm > >>> (or units per radian for rotational axis ABS_RX, ABS_RY, > >>> ABS_RZ), and if you check the binding, you can use > >>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of > >>> entire touch surface and set resolution from it so that > >>> userspace can calculate the proper scaling factor. > >> > >> How is this information exposed by the kernel to user-space? By > >> scanning the DT file or tree? > > > > Set input_abs_set_res() from kernel. And in userspace call > > EVIOCGABS ioctl() on input device. Look at struct input_absinfo, > > you should have all needed information here. This is generic input > > interface, no DT is needed. > > This assumes that I can and want to write a graphics system myself. Not only. There are already existing graphics systems. And you need to provide needed information from kernel, so they can start using it. So input_abs_set_res() is needed to use in your kernel driver. > > I hope that XServer is already using it for evdev devices... > > No idea if it does. It is a black box for me out of our control. https://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/tree/src/evdev.c#n1479 So yes, it does. > > For whole implementation look at evtest program. That should be > > good starting point for your userspace implementation. > > The problem I have is that *I* have no userspace implementation and > the GTA04 project does not want to enforce one. We have several > different ones: X11 based (LXDE and others), Qt (fb based), > Replicant to name some. > > All have the same problem to be solved once. The common denominator > for a solution are 2 lines of code in the kernel plus some DT > properties you need anyways if calibration should be automated in > userland. As I wrote above part of linux input API is resolution value. And from all information I understood that having current value, minimal value, maximal value and resolution is enough for correct calculation of pixel coordinates in userspace. And Xserver evdev driver is using it. If other non-X11 application (which you want/need to use) use resolution information incorrectly (or calculate positions incorrectly), then this is bug that application. Not in Linux kernel, that is important. And I would rather see fixes of such bugs in that (broken) application as doing workarounds in kernel, just because of bugs in application. More important, are those applications really broken? From my point of view: Reporting size of input device is already part of stable kernel <--> userspace API/ABI and it should be used instead of inventing new way... > > While I'm watching this discussion... in my opinion kernel should > > just invert input axes (when needed) and should not do any other > > normalization or integer/floating-point > > re-calibration/re-calculation. If it correctly exports minimum > > value, maximum value and resolution then userspace can correctly > > re-scale input events to units which userspace needs (e.g. mapping > > into LCD screen pixels or whatever is needed). > > It can, but afaik it does not yet. I did not tested it, but code is in xf86-input-evdev already there. So please try to implement input_abs_set_res() in kernel driver and test userspace. > And if it does, it does it in a > plethora of different implementation states. That is the reason why > we want to solve it once for all userlands in the kernel and not > rely on user-space help. For me this looks like "we are going to fix userspace bugs in kernel". Really! Not a good idea. Plus I still see this as abusing kernel API/ABI as resolution should be handled differently as you are proposing. > Surely, userland can do a lot of things. It could also do the whole > file system stuff (FUSE). > > A more input device related example comes to my mind: userland could > do keyboard mapping completely. It would suffice if the kernel > presents some x/y coordinates or gpio-numbers for buttons and > user-space could map. Still there is a (pre-)mapping to Key-Codes. > And yes, they are mapped a second time in userland if needed, but it > works sufficiently well if not done. > > BR and thanks, > Nikolaus -- Pali Rohár pali.rohar@gmail.com
[toc] | [prev] | [next] | [standalone]
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
Back to top | Article view | linux.kernel
csiph-web