|Summary:||Mouse position is calculated wrongly with Xdmx|
|Component:||Server/General||Assignee:||Peter Hutterer <peter.hutterer>|
|Status:||RESOLVED FIXED||QA Contact:||Xorg Project Team <xorg-team>|
|i915 platform:||i915 features:|
Description Sybren 2012-07-09 10:27:01 UTC
On my linux system with Xorg version 1.12.2, I simulated a dual-screen setup using the following commands: Xnest :2 -ac -xinerama -geometry 640x480+0+0 & Xnest :3 -ac -xinearam -geometry 640x480+0+0 & Xdmx :4 -norender -noglxproxy -xinerama -display :2 -display :3 -input :0 & Then I ran "xterm -display :4.1", and in the xterm I started twm. The problem: I could now move the xterm, but only in the y-direction. The x-position remained fixed. What I found: I tried to pinpoint the problem. I got to some point, which could be the problem, but it could also be just a symptom. I found that something goes wrong in the scale_from_screen function (dix/getevents.c, line 829 and beyond). In that function, the coordinates are first added to the screen's offset (scr->x or scr->y), and the result is scaled from the screen axis to the device axis. As an example with some input, this is what happens given the above setup: say the mouse gets x-coordinate 230 on the second screen (:4.1). The valuator (I checked) then gets value 230. The scale_from_screen-function then calculates the following: scaled = 230 + 640 = 870 scaled = (scaled - 0)*(1280-0)/(640-0) + 0 = scaled*2 = 1740 The two screens combined are 1280 wide, so 1740 is clearly too much. I don't exactly know whether the input values or the algorithm is wrong, but at least the result is wrong. (It gets clipped to 1280 in later processing, which explains why the movement in the x-direction is restriced.)
Comment 1 Sybren 2012-07-12 14:02:46 UTC
Created attachment 64140 [details] [review] Patch which apparently solves the problem
Comment 2 Sybren 2012-07-12 14:22:01 UTC
I looked a little further, and it seems to be a two-fold problem. The scale_from_screen function seems to scale wrongly. If my understanding is correct, the scale_from_screen function should add the screen's offset to get coordinates in the desktop's coordinate system. It should then scale from the desktop coordinates to the device's coordinates. I attached a patch which does this, making use of the desktop dimensions in screenInfo (like the scale_to_desktop function, which I think does more or less the inverse of scale_from_screen). However, the desktop dimensions in screenInfo do not seem to get updated in Xdmx. Therefore, I added update_desktop_dimensions() to dmxcursor.c near the place where screenInfo.screens is updated. I don't know if this is the right thing to do, but it seemed to make sense.
Comment 3 Peter Hutterer 2012-11-09 04:07:40 UTC
can you provide a patch for the Xdmx fix please? thanks
Comment 4 Sybren 2012-11-09 12:26:08 UTC
Created attachment 69808 [details] [review] Patch for Xdmx Since I already supplied a possible patch for both dix and Xdmx, I'm guessing you want one for Xmdx only.
Comment 5 Peter Hutterer 2012-11-13 05:38:42 UTC
Can I get your full name for the patch please? we generally don't merge patches with just the first/last/nickname. ACK to the DMX patch for sure, the other part I need to test first to make sure it doesn't break any other configurations.
Comment 6 Peter Hutterer 2012-11-27 01:30:45 UTC
Comment 7 Sybren 2012-11-27 18:31:59 UTC
Created attachment 70673 [details] [review] Patch for Xdmx Sorry for the late response. I've made a new patch with my name.
Comment 8 Peter Hutterer 2012-12-02 23:20:18 UTC
Upstream as. Other patch still in the queue, need more testing because I suspect this may break other servers. commit 6e18599d691036eca6ff082c17727d9ffb926984 Author: Sybren van Elderen <email@example.com> Date: Tue Nov 27 19:27:10 2012 +0100 hw/dmx: add update_desktop_dimensions() call