Ticket #1244 (closed defect: fixed)

Opened 7 years ago

Last modified 6 years ago

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

Reported by: will@… Owned by: john_lee
Priority: highest Milestone:
Component: kernel Version:
Severity: major Keywords:
Cc: buglog@…, tony@…, brianwc@…, thehans@…, nomeata, chgros, Yorick, ritz, dodji@…, ole.d@…, timo.lindfors@…, cjb, xeros Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:
Reproducible:

Description

Swap orientation horizontal view not calibrated

Attachments

0001-Fix-x-coord-of-input-when-rotated.patch (1.6 KB) - added by cjb 6 years ago.
xglamo-scaling.diff (3.3 KB) - added by chgros 6 years ago.
Patch with scaling only

Change History

comment:1 Changed 7 years ago by erin_yueh@…

  • Owner changed from erin_yueh@… to tony@…
  • Cc tony@… added
  • Component changed from Applications & Dependencies to kernel

hi Tony, please check this bug. Thanks!

comment:2 Changed 6 years ago by andy

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

comment:3 Changed 6 years ago by 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.

comment:4 Changed 6 years ago by 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

comment:5 Changed 6 years ago by roh

  • Owner changed from tony@… to tony_tu

comment:6 Changed 6 years ago by 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.

comment:7 Changed 6 years ago by brianwc

  • Cc brianwc@… added

comment:8 Changed 6 years ago by peepsalot

  • Cc thehans@… added

comment:9 Changed 6 years ago by nomeata

  • Cc nomeata added

comment:10 Changed 6 years ago by kenrestivo

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

comment:11 Changed 6 years ago by chgros

  • Cc chgros added

comment:12 Changed 6 years ago by ecraven

  • Severity changed from normal to major

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)!

comment:13 Changed 6 years ago by yarikoptic

  • Priority changed from high to highest

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 ;)

comment:14 Changed 6 years ago by 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).

comment:15 Changed 6 years ago by 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.

comment:16 Changed 6 years ago by Yorick

  • Cc Yorick added

comment:17 Changed 6 years ago by ritz

  • Cc ritz added

comment:18 Changed 6 years ago by 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).

comment:19 Changed 6 years ago by 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.

comment:20 follow-up: ↓ 22 Changed 6 years ago by thomasg

  • Owner changed from tony_tu to dodji@…
  • Status changed from new to assigned
  • Version unspecified deleted
  • Cc dodji@… added

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.

comment:21 Changed 6 years ago by odlg

  • Cc ole.d@… added

comment:22 in reply to: ↑ 20 Changed 6 years ago by 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...

comment:23 follow-up: ↓ 24 Changed 6 years ago by 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.

comment:24 in reply to: ↑ 23 Changed 6 years ago by 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.

comment:25 Changed 6 years ago by 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.

comment:26 Changed 6 years ago by Yorick

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

comment:27 Changed 6 years ago by 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

comment:28 follow-up: ↓ 29 Changed 6 years ago by 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.

comment:29 in reply to: ↑ 28 Changed 6 years ago by 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.

comment:30 Changed 6 years ago by chgros

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

comment:31 Changed 6 years ago by lindi

  • Cc timo.lindfors@… added

comment:32 Changed 6 years ago by 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.

comment:33 Changed 6 years ago by 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.)

comment:34 Changed 6 years ago by cjb

  • Cc cjb added

comment:35 Changed 6 years ago by cjb

  • Status changed from assigned to in_testing

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.

Changed 6 years ago by cjb

comment:36 Changed 6 years ago by 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.

comment:37 Changed 6 years ago by 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.

comment:38 Changed 6 years ago by xeros

  • Cc xeros added

comment:39 Changed 6 years ago by graeme

  • Status changed from in_testing to closed
  • Resolution set to fixed

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.

comment:40 Changed 6 years ago by Yorick

  • Status changed from closed to reopened
  • Resolution fixed deleted

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.

comment:41 Changed 6 years ago by 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)

comment:42 Changed 6 years ago by 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!

comment:43 Changed 6 years ago by 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.

comment:44 Changed 6 years ago by 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.

comment:45 Changed 6 years ago by 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.

comment:46 Changed 6 years ago by chgros

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

Changed 6 years ago by chgros

Patch with scaling only

comment:47 follow-up: ↓ 48 Changed 6 years ago by 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!

comment:48 in reply to: ↑ 47 Changed 6 years ago by 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!

comment:49 Changed 6 years ago by john_lee

  • Status changed from reopened to assigned
  • Owner changed from dodji@… to john_lee
  • HasPatchForReview unset

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

comment:50 Changed 6 years ago by john_lee

  • Status changed from assigned to closed
  • Resolution set to fixed

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

Note: See TracTickets for help on using tickets.