The patch provided is stale.  The code you are modifying was removed by:

commit 447f547fbb7d11ec56ea578292908192175b3828
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Fri Dec 3 09:29:36 2010 +1000

    Drop close_proc, conversion_proc, reverse_conversion_proc
    
    All three are not called by the server anymore.
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    Reviewed-by: Cyril Brulebois <kibi@debian.org>

Do you still have problems?  If so, can you provide an updated patch?

*** Bug 24743 has been marked as a duplicate of this bug. ***

I believe the problem is common to all touchscreen drivers now that conversion_proc is no longer called.

On point of sale terminals it's not uncommon to have a touchscreen as a primary display for the operator, with a plain old LCD as a secondary, customer-facing display.

Because there's no way to tie an input device to a specific display, Xinerama head, or screen region, the touchscreen calibration has to change when a secondary display is added or removed, or if it's replaced with a screen of a different resolution, or if the cable falls out.

I'm changing the component from elographics to Server/Input/Core because I've run into this problem recently with several drivers including mutouch, elographics, and evdev.

I think this is the closest already existing bug that is related to my
tribulation with the X server. My mail on the Xorg list is at:
http://lists.x.org/archives/xorg/2015-October/057703.html

Recently I have started working with a POS machine with touchscreen and
an Intel chip. The problem I faced made Chris Wilson to modify the
Intel DDX driver:

commit 94d271b239d358f71ae0bcfcc31422a569d73d41
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Oct 30 18:07:37 2015 +0000

    sna: Allow pipes to be manually assigned to ZaphodHead

So, at least with the Intel driver, one can manually assign the built-in
video output (LCD or LVDS that has the touchscreen attached to it) to
Screen 0 or DISPLAY=:0.0, no matter how the POS was wired internally.
Ours happen to be wired in a way that the external VGA is the primary output.

I did further testing after this driver fix and reported my finding at:
http://lists.x.org/archives/xorg/2015-October/057716.html

Let me describe it here, too. This is where I found this bug report and my
testing result is relevant here.

Despite that I am using completely independent X screens (Zaphod mode) with
no intention to use Screen 1 interactively, Xinput uses the largest of the
screen resolutions if both outputs are attached. The built-in LVDS has an
1024x768 panel attached but if an 1080p external monitor is attached, the
touchscreen coordinates are interpreted according to the 1080p resolution.

The problem with this is that the screens behave like they were aligned
at the top-left (0,0) point. In my configuration, I intentionally didn't
specify the second screen's position relative to the first, so it may be
the reason of this behaviour. If I touch the touchscreen outside the top-left
1024x768 area as it is interpreted by the touchscreen, the cursor pointer
jumps to Screen 1 and stays there until the Xorg server is restarted.

If the resolution of Screen 1 is limited to the same resolution of Screen 0
or lower, then this pointer jump doesn't happen.

The best solution would be the proposal of this bug: make the touchable area
configurable in a way to allow:
* binding the touchscreen to a screen number (i.e. by making it a non-core
  pointer?)
* allow changing the touchable area (top-left coordinate and width/height)
  if the touchscreen's monitor happens to have another monitor associated
  to the left of it.

This would allow a touchscreen work on single-monitor Zaphod mode and in
Xinerama mode or in mixed mode, i.e. in Zaphod mode with multiple monitors
associated to screens.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/591.