Xglamo doesn't handle switch to landscape mode correctly (was: Swap orientation horizontal view not calibrated)

[will@…]

Swap orientation horizontal view not calibrated

[erin_yueh@…]

hi Tony, please check this bug. Thanks!

[andy]

Can someone explain a bit more about what a "not calibrated" "horizontal view" looks like and why it is bad?

[ChaosEagle]

If I'm not mistaken, that means that even though the screen dimensions are switched, the touchscreen still seems to assume its taller than wide, resulting in every click on the screen landing somewhere it shouldn't, because the coordinates of the visible screen don't seem to match the coordinates of the clickable screen. This bug makes the landscape mode virtually useless, because you cant' hit anything with the stylus anymore.
Happens here too, Image 2007.2 dated 07/06/2008 on GTA02.

[goldie]

I confirm.
For example playing Mines (30x16) in horizontal view with the stylus gives me an 10 field offset to the left. Taping on 10th field (counting from top left) the 1st field is selected.

Openmoko-openmoko-devel-image-glibc-ipk-P1-Snapshot-20080708-om-gta02

[brianwc]

I also get this problem on my FreeRunner?, running latest recommended 2007.2 kernel and rootfs. This bug makes it impossible to effectively use landscape mode.

[kenrestivo]

I have experienced this same bug. The touchscreen is useless in landscape mode, on both the 2007.02 release and ASU.

[ecraven]

Happens on all images i tried, also on a custom Debian install (using Xglamo).
please fix this (or describe how and where to fix it)!

[yarikoptic]

confirm the bug and confirm its urgency... in debian it would be a release critical one!
If it takes more bug reports to bring attention of developers to it, I promise to post 1 a day ;)

[yarikoptic]

additional information: if I run ts_calibrate while in horizontal mode, it calibrates (seems to be in portreit), but then goes back to horizontal but offset 1/4oth of the screen to the right... though seems to be matching the keys on the keyboard (at least some).
calibration and offset is reset after phone locks and I unlock it (or just if I swap orientation again).

[Yorick]

This bug is very annoying. It is preventing the use of scummvm also. When I move the stylus to the right buttom corner i can get the TS to detect the point of contact correctly, but when I move the stylus too far to the left, if gets once again the wrong offset.

Swithing back from landscape mode also doesn't work as it should.

[thomasg]

As said on the mailinglist, this problem is a little bit weird for me.
I have the wrong calibration and offset about 150px in all the 2007.2 builds I've tried and in some inofficial builds (e.g. from alphaone).

But I don't experience this problems with ALL ASU builds I've ever tried (example 20080718). Kernel was 2.6.24, mostly the version of the same daily build I've tried.
Also the FSO Milestone 1 release works (FSO MS1 rootfs + FSO MS1 kernel).

[Yorick]

This is how i get it to work *more or less* on the ASU:
flash to kernel 28/07
flash to rootfs 22/07
no opkg upgrade

I install and run scummvm and then there is no offset.
When I click on a corner and the click somewhere in the middle of the screen the offset is reintroduced:
When I press left upper corner and then press 20pixels to the right, I get an offset of 20pixels.
When I press left upper corner and then press 30pixels to the right, I get an offset of 30pixels.
There is maximum on the amount of offset though (approximately half the screen).
Pressing another corner will make the cursor jump to that corner.

To minimize the offset one has to press on a corner and drag the stylus away from it.

[thomasg]

Ok guys, I just spent some minutes figuring out what the problem causes and why they are on one image and not on another:
ASU still uses Xfbdev as X-Server - the did _not_ yet switch on Xglamo.
This means the rotation is done in pure Software, but at least working.
This also means, that the reason for the bug is Xglamo itself.
I checked the calibration, this doesn't cause the problem's, it's only a bug in the Xglamo X-server.

As we now this for sure now, I'll change the component to System Software and reassign the bug to Dodji, as I assume he is still in charge for Xglamo.

[Yorick]

Replying to thomasg:

Ok guys, I just spent some minutes figuring out what the problem causes and why they are on one image and not on another:
ASU still uses Xfbdev as X-Server - the did _not_ yet switch on Xglamo.
This means the rotation is done in pure Software, but at least working.
This also means, that the reason for the bug is Xglamo itself.
I checked the calibration, this doesn't cause the problem's, it's only a bug in the Xglamo X-server.

As we now this for sure now, I'll change the component to System Software and reassign the bug to Dodji, as I assume he is still in charge for Xglamo.

Are you sure about this?
I use the ASU and i still get the wrong ofset when clicking on a corned and afterwards clicking on a random part of the screen...

[thomasg]

I'm 100% sure.
I used the ASU build from buildhost, 22.07.2008, that comes with Xfbdev.
Then I removed Xfbdev. installed Xglamo, started it and the error is there.
Switch back to Xfbdev and it is gone again.

Im pretty sure you are not using one of the latest ASU builds from buildhost, because they don't come with Xglamo.

So please be a bit more verbose and tell us what you are using exactly.
If you experience the problem, check if /usr/bin/Xglamo is running - I'm sure it is.

[Yorick]

Replying to thomasg:

I'm 100% sure.
I used the ASU build from buildhost, 22.07.2008, that comes with Xfbdev.
Then I removed Xfbdev. installed Xglamo, started it and the error is there.
Switch back to Xfbdev and it is gone again.

Im pretty sure you are not using one of the latest ASU builds from buildhost, because they don't come with Xglamo.

So please be a bit more verbose and tell us what you are using exactly.
If you experience the problem, check if /usr/bin/Xglamo is running - I'm sure it is.

I'm sorry to dissapoint you, but I do not have Xglamo running...
I use (as mentioned) the kernel of 0728, rootfs of 0722
This is what I get:
root@om-gta02:~# ps ax | grep Xglamo

1548 pts/0 S+ 0:00 grep Xglamo

root@om-gta02:~# ps ax | grep Xfbdev

1385 ? S 0:00 xinit /etc/X11/Xsession -- /usr/bin/Xfbdev :0 -pn -dpi 285 -screen 480x640 -hide-cursor -root-ppm /usr/share/pixmaps/xsplash-vga.ppm
1395 ? S< 7:14 /usr/bin/Xfbdev :0 -pn -dpi 285 -screen 480x640 -hide-cursor -root-ppm /usr/share/pixmaps/xsplash-vga.ppm
1550 pts/0 S+ 0:00 grep Xfbdev

Doesn't seem like I am using Xglamo and still I get the bug (when clicking on a corner)...
If you need more information, feel free to ask (or tell me what commands to run :)). I hope this info helps.

[Yorick]

another small bugg:
when exiting landscapeview (in scummvm) the buttom part of the screen does not get updated correctly (it still displays the bar "Starting <previous app that I ran in landscape>" and it displays that bar with a vertical offset (higher than it normally is displayed), opening a new app resolves this.

[Yorick]

sorry for all this spam:
it seems more likely a bug in scummvm
because it seems fine when i do xrand -o 1

[ecraven]

using debian, with Xfbdev and Xglamo copied from 2007.2:
with Xglamo, landscape is offset
with Xfbdev, it works
seems to indicate a bug in Xglamo
i tried what Yorick says, but that bug doesn't happen here, works fine
also, no problems with switching rotation.
but Xfbdev is sloooow

[ecraven]

there are problems with scummvm and fullscreen (landscape), beneath a steel sky doesn't work well at all, in monkey island 1 there are small black borders above and below the game area, by moving the mouse into them an offset is introduced. but both work fine in windowed mode.

[andy]

Replying to ecraven:

there are problems with scummvm and fullscreen (landscape), beneath a steel sky doesn't work well at all, in monkey island 1 there are small black borders above and below the game area, by moving the mouse into them an offset is introduced. but both work fine in windowed mode.

Hey that sounds like virtual screen size is a bit bigger than actual somehow... that would explain this offset business since touchscreen continues to give absolute coords unaware the viewport moved.

[cjb]

I'd like to help with this if I can. So far, do we think that it's:

• virtual screen size being set wrong
• glamo not noticing that the viewport changed
• glamo noticing, but not performing input rotation properly
• something else?

Thanks.

[cjb]

I tried adding:

KdComputeMouseMatrix (&m, randr, screen->width, screen->height);
KdSetMouseMatrix (&m);

to the bottom of GLAMORandRSetConfig(), but with no change in behavior; looks like they're already called by glamoSetScannoutGeometry() in any case. (This is what drivers normally do; catch an RandR event and do input rotation then.)

[cjb]

Okay, worked it out, patch attached. Note that this only fixes the x-coord input rotation offset problem -- people with application windows that aren't rotating properly probably want to find a different bug for that.

[alphaone]

This works pretty well for most things, good work!

Though still if I switch from one of the landscape modes (-o 1 or 3) to upside down (-o 2) the ts input is offset again.
If I switch from the landscape modes into the other landscape mode the display itself is offset, but ts and display are in sync.

[cjb]

Yup, the only calls affected by the patch are input related, so unsurprised that display problems are unchanged. I can look at that too, though.

[graeme]

This was commited to xglamo repo as 4067470ea4d569bae7b4161ca998645a0c9b96e7

This has been updated in org.openmoko.dev and should appear in the next set of auto builds.

[Yorick]

In 2008.8 I get the same offset bug.
when running scummvm or manially setting xrandr -o 1

Dragging the cursor the a corner on the right/up side of the phone almost cancels out the offset; but when the cursor goes about 3/4 to left/bottom the cursor jumps to the left/bottom side.

[chgros]

It also looks like scaling doesn't work either:
in 240x320 mode, the mouse coordinates only both change in the lower right quarter of the screen, but still go to 240x320. The upper left quarter is completely dead. (checked by running xev)

[chgros]

I looked at the code, and it looks like there's no support for mouse scaling (rotation / offset only). I'm trying to add it, but since I'm not familiar with the code base it might be quite hackish. I'll post patches once I've got something working, and then whoever is responsible can use them. I really want this fixed!

[chgros]

I got something to work.
See attached patch.
The glamoc->backend_funcs.randrSetConfig = GLAMORandRSetConfig;fbdevRandRSetConfig;
actually handles offset in landscape mode, not scaling.

Please review.

[lindi]

Thanks chgros! The patch works fine with xrandr -s 240x320. However it does not work correctly if I also rotate the screen (xrandr -o 3). If you can figure out how to support that I'll be happy to test it.

[chgros]

xrandr -o 3 works for me (actually that was my target, I'm trying to get Duke Nukem 3D to work correctly).

The previous patch was supposed to handle the rotation issue; it's possible I broke it (it looks like my sources don't have that previous patch). In that case, suppressing the part that deals with GLAMORandRSetConfig might fix your problem.

[chgros]

I checked with more recent sources, and undoing the GLAMORandRSetConfig change seems to do the trick.

[chgros]

Patch with scaling only

[chgros]

Any chance this patch might make it into 2008.10 or whatever the next update is? It's important as it allows to play vga resolution games. Thanks!

[scarlson]

Replying to chgros:

Any chance this patch might make it into 2008.10 or whatever the next update is? It's important as it allows to play vga resolution games. Thanks!

I second that! I have a few game ports to release!

[john_lee]

Applied the attached patch but scale doesn't work yet. Will look into this.

[john_lee]

Turns out to be the problem of illume-theme-asu. Patch applied as 7fa46527131177dfba7e711d1530205a9efc5e79