MinY < MaxY leads to unexpected behaviour

Bug #218671 reported by reinhard
40
Affects Status Importance Assigned to Milestone
xserver-xorg-input-elographics (Ubuntu)
Fix Released
High
Unassigned
Hardy
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: xserver-xorg-input-elographics

Hello,
within our configuration directions of coordinates differs for elographics driver against the screen Directions.

With previous versions of xserver-xorg-input-elographics we were able to correct this by swapping min and max Values inside xorg.conf.

Section "InputDevice"
        Identifier "EloTouch"
        Driver "elographics"
....
        Option "MinY" "4159"
        Option "MaxY" "98"
....
EndSection

On hardy the cursor hangs on the edge of the display if we do this. With MinY < MaxY touch works as expected except for the swapped y-direction.

Versions used:
Ubuntu 8.04 beta
xserver-xorg 1:7.3+10ubuntu10
xserver-xorg-input-elographics 1:1.1.0-3
xserver-xorg-video-intel 2:2.2.1-1ubuntu12

Revision history for this message
Matthew Darwin (bugs-mdarwin) wrote :

Confirmed in released version of 8.04. (See duplicate bugs)

Revision history for this message
gizwill (gizwill) wrote :

I have the same bug with 8.04

Revision history for this message
gator4 (maryjane136) wrote :

Fixed in source package xf86-input-elographics-1.2.2.tar.gz (Debian unstable)
Cursor movement works properly now.
But still not recommended:

- After the first touch keyboard and mouse (both PS2) inputs are disabled
- Touch do not perform a "mouse click"

Tested with Xubuntu 8.04 and ELO 1739L Accutouch.

Revision history for this message
Area51 (wout-bettens) wrote :

Confirmed in Xubuntu 8.04 with xf86-input-elographics-1.2.2

- Y-Axis is not inverted anymore and the calibration is okay now
- Mouse and keyboard (both USB) are frozen after touching the screen
- Touch does not perform 'mouse click'

Hopefully this will be fixed soon...

Revision history for this message
furicle (furicle) wrote :

confirmed here as well.

Revision history for this message
ouellettesr (ouellette-kevin) wrote :

Confirmed.

Revision history for this message
BastiBense (basti-bense) wrote :

Confirmed/fixed?

The vertical/Y-axis is inverted after upgrading to hardy.

I attached a quick patch to address this problem and it seems to work just fine on my system. The problem is that for some reason the touch screen provides the touch-position from the bottom of the screen while Xorg assumes the value from the top.

The patch simply inverts the Y-axis again and it seems to work just fine for me. Warning: I have tested this only on a POS-touchscreen on a customer's system. I can't gurantee that the inversion-problem now happens on other devices.

To build a fixed package on hardy (you need the default tools to build packages from source - see google):

apt-get source xserver-xorg-input-elographics
cd xserver-xorg-input-elographics-1.1.0/src/
patch -p0 < /path/to/xf86Elo_fix.diff
cd ..
debuild
dpkg -i ../xserver-xorg-input-elographics_1.1.0-3_i386.deb

Restart Xorg and see if the Y-axis is correctly working again.

Revision history for this message
BastiBense (basti-bense) wrote :

Forget the first part of the patch (row 733), that was just a changed line break. :)

Revision history for this message
furicle (furicle) wrote : Re: [Bug 218671] Re: MinY < MaxY leads to unexpected behaviour

This patch fixes the problem for me too! Thanks!

Since it looks like a pretty simple patch, hopefully someone can apply
it without a whole lot of review being required.

Thanks again....

Brian

Revision history for this message
BastiBense (basti-bense) wrote :

Someone should verify that this doesn't cause problems on other models of ELO touchscreens. In the first place I'd like to know why the Y-axis got inverted all of the sudden... Is this due to a change in Xorg?

BastiBense (basti-bense)
Changed in xserver-xorg-input-elographics:
status: New → Confirmed
Revision history for this message
Area51 (wout-bettens) wrote :

Great !
The patch works fine, on Xubuntu 8.04

Thank you very much

Revision history for this message
BastiBense (basti-bense) wrote :

Ah, I finally got some information about what touch panel the POS system is using:

(--) Elographics touchscreen is a AccuTouch, connected through a serial link.
(--) The controller is a model E271-2200, firmware revision 1.0.

Revision history for this message
furicle (furicle) wrote :

On Fri, Aug 1, 2008 at 8:50 AM, Cheetahcat <email address hidden> wrote:
> Ah, I finally got some information about what touch panel the POS system
> is using:
>
> (--) Elographics touchscreen is a AccuTouch, connected through a serial link.
> (--) The controller is a model E271-2200, firmware revision 1.0.

What's a reliable way to get this info? Mine is serial, but the
monitor is just labelled as a standard LG model. I don't see any
external indications.

Brian

Revision history for this message
BastiBense (basti-bense) wrote :

> What's a reliable way to get this info? Mine is serial, but the
> monitor is just labelled as a standard LG model. I don't see any
> external indications.
>
> Brian

This info should be in the Xorg.log (/var/log/Xorg.0.log). Simply search for "Elo" and you should find the info formatted exactly like the one I posted before.

Revision history for this message
impulze (kristian-ek) wrote :

I get to the point where I use sudo debuild and it turns out with an error:

debuild: fatal error at line 1247

Can anybody help me with this?

Revision history for this message
furicle (furicle) wrote :

On Fri, Aug 1, 2008 at 10:47 AM, BastiBense <email address hidden> wrote:
>> What's a reliable way to get this info? Mine is serial, but the
>> monitor is just labelled as a standard LG model. I don't see any
>> external indications.
>>
>> Brian
>
> This info should be in the Xorg.log (/var/log/Xorg.0.log). Simply search
> for "Elo" and you should find the info formatted exactly like the one I
> posted before.

So mine is an
 Elographics touchscreen is a AccuTouch, connected through a serial link.
 The controller is a model E271-2210, firmware revision 1.4.
 Additional features:
    External A/D converter

HTH
Brian

Revision history for this message
alendubri (alendubri) wrote :
Download full text (3.2 KiB)

Hi to all on the Forum!

I installed Ubuntu 8.04 on an industrial PC with integrated touchpad. The touchpad is connected by the serial interface /dev/ttyS1. Then I use the xserver-xorg-input-elographics package. The X system reports the following (on Xorg.0.log):
--------------------------
(--) Elographics touchscreen is a AccuTouch, connected through a serial link.
(--) The controller is a model E271-2200, firmware revision 2.0.
--------------------------

And I have the following Xorg configuration:

--------------------------
Section "InputDevice"
        Identifier "Generic Keyboard"
        Driver "kbd"
        Option "XkbRules" "xorg"
        Option "XkbModel" "pc105"
        Option "XkbLayout" "de"
EndSection

Section "InputDevice"
        Identifier "Configured Mouse"
        Driver "mouse"
        Option "CorePointer"
EndSection

Section "InputDevice"
        Identifier "xeloserial"
        Driver "elographics"
        Option "Device" "/dev/ttyS1"

        Option "MinX" "465"
        Option "MaxX" "3658"
        Option "MaxY" "3514"
        Option "MinY" "512"
        Option "ScreenNumber" "0"
        Option "ReportingMode" "Raw"
        Option "ButtonThreshold" "17"
        Option "ButtonNumber" "1"
        Option "SendCoreEvents"
EndSection

Section "Device"
        Identifier "Configured Video Device"
EndSection

Section "Monitor"
        Identifier "Configured Monitor"
EndSection

Section "Screen"
        Identifier "Default Screen"
        Monitor "Configured Monitor"
        Device "Configured Video Device"
EndSection

Section "ServerLayout"
        Identifier "Default Layout"
        Screen "Default Screen"
        InputDevice "Generic Keyboard"
        InputDevice "Configured Mouse"
        InputDevice "xeloserial"
EndSection
--------------------------
I used touchcal-0.31 to make the calibration.

With this configuration and the default elographics module I had a problem with the direction of the Y coordinate, It was inverted. I try to use the option "SwapY", inverted the MinY,MaxY values, etc. Until I found your bug report.

I download I compile the xf86-input-elographics-1.2.2.tar.gz, I worked, but I had no Mouse and no keyboard response, and the X server could not be killed. The Xorg.0.log was full of the following 2 lines:
-------------------------
mieqEnequeue: out-of-order valuator event; dropping.
tossed event which came in late
-------------------------

Than I made a comparison between 1.1.0 and 1.2.2 and made patches for the file xf86Elo.c. Now works fine, at least for me. I will publish 2 patches, one is to patch the xf86-input-elographics-1.1.0.tar.gz package and the other to the xf86-input-elographics-1.2.2.tar.gz package. The patch for 1.2.2 shows that the event generation is on a while loop, that must not be.

I make the patch agaist 1.1.0 because this is the version that is used by ubuntu 8.04 by default. I hope this will be useful to other people that want ...

Read more...

Revision history for this message
alendubri (alendubri) wrote :
Download full text (3.2 KiB)

Hi to all on the Forum!

I installed Ubuntu 8.04 on an industrial PC with integrated touchpad. The touchpad is connected by the serial interface /dev/ttyS1. Then I use the xserver-xorg-input-elographics package. The X system reports the following (on Xorg.0.log):
--------------------------
(--) Elographics touchscreen is a AccuTouch, connected through a serial link.
(--) The controller is a model E271-2200, firmware revision 2.0.
--------------------------

And I have the following Xorg configuration:

--------------------------
Section "InputDevice"
        Identifier "Generic Keyboard"
        Driver "kbd"
        Option "XkbRules" "xorg"
        Option "XkbModel" "pc105"
        Option "XkbLayout" "de"
EndSection

Section "InputDevice"
        Identifier "Configured Mouse"
        Driver "mouse"
        Option "CorePointer"
EndSection

Section "InputDevice"
        Identifier "xeloserial"
        Driver "elographics"
        Option "Device" "/dev/ttyS1"

        Option "MinX" "465"
        Option "MaxX" "3658"
        Option "MaxY" "3514"
        Option "MinY" "512"
        Option "ScreenNumber" "0"
        Option "ReportingMode" "Raw"
        Option "ButtonThreshold" "17"
        Option "ButtonNumber" "1"
        Option "SendCoreEvents"
EndSection

Section "Device"
        Identifier "Configured Video Device"
EndSection

Section "Monitor"
        Identifier "Configured Monitor"
EndSection

Section "Screen"
        Identifier "Default Screen"
        Monitor "Configured Monitor"
        Device "Configured Video Device"
EndSection

Section "ServerLayout"
        Identifier "Default Layout"
        Screen "Default Screen"
        InputDevice "Generic Keyboard"
        InputDevice "Configured Mouse"
        InputDevice "xeloserial"
EndSection
--------------------------
I used touchcal-0.31 to make the calibration.

With this configuration and the default elographics module I had a problem with the direction of the Y coordinate, It was inverted. I try to use the option "SwapY", inverted the MinY,MaxY values, etc. Until I found your bug report.

I download I compile the xf86-input-elographics-1.2.2.tar.gz, I worked, but I had no Mouse and no keyboard response, and the X server could not be killed. The Xorg.0.log was full of the following 2 lines:
-------------------------
mieqEnequeue: out-of-order valuator event; dropping.
tossed event which came in late
-------------------------

Than I made a comparison between 1.1.0 and 1.2.2 and made patches for the file xf86Elo.c. Now works fine, at least for me. I will publish 2 patches, one is to patch the xf86-input-elographics-1.1.0.tar.gz package and the other to the xf86-input-elographics-1.2.2.tar.gz package. The patch for 1.2.2 shows that the event generation is on a while loop, that must not be.

I make the patch agaist 1.1.0 because this is the version that is used by ubuntu 8.04 by default. I hope this will be useful to other people that want ...

Read more...

Revision history for this message
alendubri (alendubri) wrote :

Sorry for the duplicate comment :-( it was a failure of a newbie on launchpad....

Here goes the second patch file.

Regards,

    Alberto E. Dubuc B. (alendubri)

Revision history for this message
GideonRomm (gideon) wrote :

This patch fixed thigns for me in Hardy! Here is a package for Hardy...

-Gadi

Revision history for this message
Stéphane Graber (stgraber) wrote :

I just had the issue, applying the patch and rebuilding the driver solved it. (In Intrepid)

Changed in xserver-xorg-input-elographics:
importance: Undecided → High
status: Confirmed → Triaged
Revision history for this message
Martin Pitt (pitti) wrote :

Bryce, can you please review this and upload to hardy/intrepid-proposed, and make sure it gets into jaunty? It seems to be fixed upstream in 1.2.2. Thanks!

Changed in xserver-xorg-input-elographics:
assignee: nobody → bryceharrington
Bryce Harrington (bryce)
Changed in xserver-xorg-input-elographics:
assignee: nobody → bryceharrington
Revision history for this message
TJ (tj) wrote :

I've added alendubri's patched version for Hardy into my PPA:

https://edge.launchpad.net/~intuitivenipple/+archive?field.name_filter=xserver-xorg-input-elographics&field.status_filter=published

I'm also attaching a debdiff for Hardy (1:1.1.0-3ubuntu1).

Revision history for this message
Dominic (dominic-letourneau) wrote :

Hello,

I am using Ubuntu 8.10 Intrepid with the elographics touchscreen driver. My xorg.conf configuration is the same as the one previously posted on this thread. I still have problems with the freezing of the mouse and keyboard and it does not seem to work since I touch the screen and no mouse click happen. I see the mouse pointer move when I touch though.

Is the patch previously mentioned integrated in Intrepid?

Thanks for your help!

Dominic

Revision history for this message
Dominic (dominic-letourneau) wrote :

Here is my touchscreen section in xorg.conf

#########################
# Touchscreen section #
#########################
Section "Inputdevice"
        Identifier "TouchScreen"
        Driver "elographics"
        Option "Device" "/dev/ttyS1"
# Option "AlwaysCore"
        Option "ScreenNumber" "0"
        Option "MinX" "3500"
        Option "MaxX" "600"
        Option "MinY" "600"
        Option "MaxY" "3400"
# Option "UntouchDelay" "2"
# Option "ReportDelay" "1"
 Option "PortraitMode" "Portrait"
 Option "SwapXY" "true"
 Option "SendCoreEvents"
        Option "ReportingMode" "Raw"
        Option "ButtonThreshold" "17"
        Option "ButtonNumber" "1"
EndSection

Dominic

Revision history for this message
Bryce Harrington (bryce) wrote :

> Bryce, can you please review this and upload to hardy/intrepid-proposed, and make sure it gets into jaunty? It seems to be fixed upstream in 1.2.2. Thanks!

Martin, are you certain this should be uploaded? This bug has a number of irregularities...

1. Several patches are mentioned in this bug report (comments #7, #18, #19, #23) each of which is different. I'm assuming you mean patch #7 should go in. However, in reviewing this patch I don't think it's a proper fix. Presumably the current axis settings in -elographics at least works for some hardware, else why would they have coded it that way? But this patch reverses the y-axis. I can believe that there may be some hardware that has backwards y-axes, which this patch would fix, however I would think this would thence cause regressions for all existing hardware with y-axes that go the other direction.

2. In addition, patch #7 is not upstream (neither is patch #19) so this conflicts with a few people who indicate the problem is fixed with the 1.2.2 release. Are multiple bugs being reported in this report?

3. The only code change from 1.2.1 to 1.2.2 simply adds a check for XINPUT ABI version 3. This would fix an ABI breakage issue, which would have very different symptoms than this bug. So while that looks like a safe and easy fix to backport, I really don't think it's what is needed to fix this issue.

Due to these irregularities, I'd be much more comfortable if this patch were taken upstream before considering whether to accept it for SRUing. I think there's just too much risk of regression.

Revision history for this message
Bryce Harrington (bryce) wrote :

Basically I agree with comment #10. This bug should go upstream for review. I have a suspicion that there is something hardware-specific about this bug, but unfortunately none of the many people who have confirmed this issue have indicated what hardware they have, so it's impossible to determine this as the case, nor to develop a proper fix that conditionalizes the y-axis swap for that specific hardware.

So, before we can even upstream the bug, we must have this information. Attach the detailed lshal / lsusb / lsinput data that identifies the hardware you're using with -elographics.

Changed in xserver-xorg-input-elographics:
assignee: bryceharrington → nobody
status: New → Incomplete
Revision history for this message
Bryce Harrington (bryce) wrote :

[Marking incomplete due to missing information, and patch needing further work to avoid causing regressions for non-affected users.]

Changed in xserver-xorg-input-elographics:
assignee: bryceharrington → nobody
status: Triaged → Incomplete
Revision history for this message
Martin Pitt (pitti) wrote :

Thanks, Bryce. No, I am not sure at all whether this should go into stables, I just thought you could judge it much better.

Revision history for this message
furicle (furicle) wrote :

On Tue, Mar 3, 2009 at 11:38 PM, Bryce Harrington
<email address hidden> wrote:
> Basically I agree with comment #10.  This bug should go upstream for
> review.  I have a suspicion that there is something hardware-specific
> about this bug, but unfortunately none of the many people who have
> confirmed this issue have indicated what hardware they have, so it's
> impossible to determine this as the case, nor to develop a proper fix
> that conditionalizes the y-axis swap for that specific hardware.

Bryce - several of us have indicated it worked fine previously, and is
reversed in hardy. How can that be specific hardware with a swapped y
axis?

> So, before we can even upstream the bug, we must have this information.
> Attach the detailed lshal / lsusb / lsinput data that identifies the
> hardware you're using with -elographics.

I will attempt to get the lshal info if you think it will help.
AFAIK from reading reports everyone reporting this is using a serial
interface and we have given that information already -

From the earlier entries

 Elographics touchscreen is a AccuTouch, connected through a serial link.
 The controller is a model E271-2210, firmware revision 1.4

Elographics touchscreen is a AccuTouch, connected through a serial link.
The controller is a model E271-2200, firmware revision 2.0

Elographics touchscreen is a AccuTouch, connected through a serial link.
The controller is a model E271-2200, firmware revision 1.0.

I don't see however how the heck you expect us to prove whether it's
just some of the hardware or all of it. We can only test what we've
got in front of us.

Please, let me what else we can do to move this along!

Brian

Revision history for this message
Bryce Harrington (bryce) wrote :

> Please, let me what else we can do to move this along!

Filing a report upstream would be a solid step you could do to help move things along.
Once upstream accepts a patch, I tend to have a lot more confidence about pulling it into Ubuntu as well.

Revision history for this message
William Trivett (willtriv) wrote :

git master on freedesktop.org has fixed this issue. The issue still resides inside release 1.2.3. To from git you will need to pull an updated copy of xutils-dev source from launchpad and overwrite the xorg-marcos.m4 overtop the installed one from xutils-dev in repo.

also, i tested anothe version of the screen and firmware and the issues existed where the elographics was stuck in a loop.

Elographics touchscreen is a Intellitouch, connected through a serial link.
(--) The controller is a model E271-2200, firmware revision 1.5.
(--) Additional features:
(--) External A/D converter
(--) Z axis active

Bryce Harrington (bryce)
Changed in xserver-xorg-input-elographics (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Fabián Rodríguez (magicfab) wrote :

Having the same issue with an Elo TouchSystems 2700 IntelliTouch(r) USB Touchmonitor Interface (USB ID 04e7:0020).

Revision history for this message
Fabián Rodríguez (magicfab) wrote :

I am a bit puzzled that I removed all drivers and the touchscreen seems to work out of the box in Hardy for me. The suggested patches, etc. don't work for me. Here's my relevant ouput from cat /proc/bus/input/devices:

I: Bus=0003 Vendor=04e7 Product=0020 Version=0100
N: Name="Elo TouchSystems, Inc. Elo TouchSystems 2700 IntelliTouch(r) USB Touchmonitor Interface"
P: Phys=usb-0000:00:1d.1-2/input0
S: Sysfs=/devices/pci0000:00/0000:00:1d.1/usb7/7-2/7-2:1.0/input/input3
U: Uniq=20H84421
H: Handlers=mouse1 event3 js0
B: EV=1b
B: KEY=10000 0 0 0 0 0 0 0 0
B: ABS=100 3
B: MSC=10

Revision history for this message
Bryce Harrington (bryce) wrote :
Revision history for this message
Bryce Harrington (bryce) wrote :

Fabian's lspci:
00:02.0 VGA compatible controller: Intel Corporation Eaglelake Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
  Subsystem: Dell Unknown device 027f
  Flags: bus master, fast devsel, latency 0, IRQ 11
  Memory at fe800000 (64-bit, non-prefetchable) [size=4M]
  Memory at d0000000 (64-bit, prefetchable) [size=256M]
  I/O ports at ec90 [size=8]
  Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
  Capabilities: [d0] Power Management version 2

Revision history for this message
Bryce Harrington (bryce) wrote :

Fabian, just to make sure I understand, could you explain the issue you're seeing? You said it was the "same issue", but it is possible you may have an unrelated bug, so it would be helpful to hear directly.

Also, if possible it would be helpful if you could test against jaunty, which has a newer version of -elographics. If that works, then it may be a simple matter of cherrypicking the relevant fix to hardy.

Revision history for this message
Bryce Harrington (bryce) wrote :

@William, you mention that "git upstream has fixed this issue", and that the fix is not present in 1.2.3, however there is only one actual change in git that is not in 1.2.3, "Fix InputDriverRec allocation and freeing" which doesn't look like it affects coordinate swapping behavior. Please elaborate on your comment if you could.

Revision history for this message
Bryce Harrington (bryce) wrote :

I've put a hardy build of the -elographics 1.2.3 that's in Jaunty in my PPA:

  https://edge.launchpad.net/~bryceharrington/+archive/ppa/

Revision history for this message
Bryce Harrington (bryce) wrote :

I've put together a new hardy package that includes three patches from the newer upstream tree, that may help with the MinX/MinY issue, and are worth testing. If this package solves the issue on hardy, it may be reasonable to consider putting an SRU to include it as a hardy update. So please test and let me know what you find.

https://edge.launchpad.net/~ubuntu-x-swat/+archive/ppa

Revision history for this message
Bryce Harrington (bryce) wrote :

Fabian, I notice you are on an Eaglelake video chipset, which is not supported in the hardy version of -intel. You may want to try the 2.5 backport of the driver available from xorg-edgers, to see if that helps:

https://edge.launchpad.net/~xorg-edgers/+archive/ppa/+sourcepub/469034/+listing-archive-extra

Revision history for this message
Fabián Rodríguez (magicfab) wrote :

Thanks Bryce. I don't think the driver is relevant although I need to fix that too. Video playback at that that reoslution (26" screen) using VESA is unusable. Both the touchscreen and resolution issues I am having seem related although not identical to this bug, and none of the fixes proposed here work for me.

I have filed separate bugs for both:
 * EloTouch 2639L touchscreen (input device) possibly not properly recognized, XY axis inverted (Bug #362308)
 * Intel integrated Graphics [8086:2e13] resolution not properly detected, not supported in Hardy (Bug #362335)

Revision history for this message
Bryce Harrington (bryce) wrote :

On Thu, Apr 16, 2009 at 02:15:21PM -0000, Fabián Rodríguez wrote:
> I have filed separate bugs for both:
> * EloTouch 2639L touchscreen (input device) possibly not properly recognized, XY axis inverted (Bug #362308)
> * Intel integrated Graphics [8086:2e13] resolution not properly detected, not supported in Hardy (Bug #362335)

Thanks, I'll follow up there.

Revision history for this message
William Trivett (willtriv) wrote :

@Bryce
Yes, upon further reviewing the GIT upstream I did find that the fix was pre 1.2.3 and that it infact was fixed in a later release of the ubuntu package. The issue was not corrected when i upgraded the package because it did not erase the old module somehow. Once I manually removed the broken version the newer package worked fine.

@Fabian, I'm also confused about your issue as it seems he is using the elographics module with usb? I was unaware that it even supported usb. I probably should have done more snooping in the code. Could you post the device section of your xorg.conf that you are using with the elo module?

thanks

Revision history for this message
William Trivett (willtriv) wrote :

@Bryce
Yes, upon further reviewing the GIT upstream I did find that the fix was pre 1.2.3 and that it in fact was fixed in a later release of the ubuntu package. The issue was not corrected when i upgraded the package because it did not erase the old module somehow. Once I manually removed the broken version the newer package worked fine.

@Fabian, I'm also confused about your issue as it seems he is using the elographics module with usb? I was unaware that it even supported usb. I probably should have done more snooping in the code. Could you post the device section of your xorg.conf that you are using with the elo module?

thanks

Bryce Harrington (bryce)
tags: added: hardy
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

1.3.2 has been in ubuntu for some time. Leaving open for hardy.

Changed in xserver-xorg-input-elographics (Ubuntu):
status: Confirmed → Fix Released
dino99 (9d9)
Changed in xserver-xorg-input-elographics (Ubuntu Hardy):
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.