Window borders do not respond to touchscreen

Gorsh said:

Also: trying Xubuntu 12.10 Alpha 3 (Xfce 4.10) had the same behaviour.

Olivier Fourdan @olivier uploaded an attachment:

(In reply to comment 0)

[...] It's very likely another instance of this problem:

http://old.nabble.com/Xfwm-window-borders-do-not-respond-to-touch-screen- td34186548.html

... but i can't understand Olivier's suggestion about "adding traces" fully and/or how to research it further. I'll provide further data if requested; i don't know where to look or what for.

The traces were added, and showed that a fields from the event received is missing the required information, ie the subwindow is set to 0 in the event structure. xfwm4 uses that field to determine what area of the decoration was activated, without this, it can't make use of the event and discard it.

So that may look like an X server bug at first sight, but of course this needs to be investigated further before drawing any conclusion.

I am attaching a simple test program in plain C that you can use to determine if the subwindow is set appropriately.

Save the attachment as subwindow-field.c and compile it with:

$ gcc -o subwindow-field $(pkg-config --cflags --libs x11) subwindow-field.c

(Note you'll need to have the developpment packages installed to be able to compile and link the test program)

Then, once build run the test prog with:

$ ./subwindow-field

and click in the large black window, using either your mouse/touchpad or the touchscreen.

If all is well, each time you click in the black window, you should see:

*** SUCCESS *** Subwindow is set

If you see:

*** FAILURE *** Subwindow is not set

Then this is most likely a bug in the X server.

Attachment 4641, "Test program":
subwindow-field.c

Olivier Fourdan @olivier said:

Note: possible dupe of bug #9099

Gorsh said:

(In reply to comment 2)

Created attachment 4641 [details] Test program

(In reply to comment 0)

[...] It's very likely another instance of this problem:

http://old.nabble.com/Xfwm-window-borders-do-not-respond-to-touch-screen- td34186548.html

... but i can't understand Olivier's suggestion about "adding traces" fully and/or how to research it further. I'll provide further data if requested; i don't know where to look or what for.

The traces were added, and showed that a fields from the event received is missing the required information, ie the subwindow is set to 0 in the event structure. xfwm4 uses that field to determine what area of the decoration was activated, without this, it can't make use of the event and discard it.

So that may look like an X server bug at first sight, but of course this needs to be investigated further before drawing any conclusion.

I am attaching a simple test program in plain C that you can use to determine if the subwindow is set appropriately.

Save the attachment as subwindow-field.c and compile it with:
$ gcc -o subwindow-field $(pkg-config --cflags --libs x11)
subwindow-field.c

(Note you'll need to have the developpment packages installed to be able to compile and link the test program)

Then, once build run the test prog with:
$ ./subwindow-field
and click in the large black window, using either your mouse/touchpad or the touchscreen.

If all is well, each time you click in the black window, you should see:
*** SUCCESS *** Subwindow is set
If you see:
*** FAILURE *** Subwindow is not set
Then this is most likely a bug in the X server.

I installed xorg-dev, but still, the compiling is not succesful. It reads:

gcc -o subwindow-field $(pkg-config --cflags --libs x11) subwindow-field.c

/tmp/cc4Yc0U5.o: In function main': subwindow-field.c:(.text+0x2c): undefined reference to XOpenDisplay' subwindow-field.c:(.text+0x127): undefined reference to XCreateSimpleWindow' subwindow-field.c:(.text+0x177): undefined reference to XCreateSimpleWindow' subwindow-field.c:(.text+0x197): undefined reference to XSelectInput' subwindow-field.c:(.text+0x1ab): undefined reference to XMapWindow' subwindow-field.c:(.text+0x1bf): undefined reference to XMapWindow' subwindow-field.c:(.text+0x1d6): undefined reference to XNextEvent' collect2: ld devolvió el estado de salida 1

It seems i'm still missing a dev package, but can't tell which; i've been going through "xorg + dev" at synaptic and installing everything that looks relevant, to no avail.(In reply to comment 2)

Created attachment 4641 [details] Test program

(In reply to comment 0)

[...] It's very likely another instance of this problem:

http://old.nabble.com/Xfwm-window-borders-do-not-respond-to-touch-screen- td34186548.html

... but i can't understand Olivier's suggestion about "adding traces" fully and/or how to research it further. I'll provide further data if requested; i don't know where to look or what for.

The traces were added, and showed that a fields from the event received is missing the required information, ie the subwindow is set to 0 in the event structure. xfwm4 uses that field to determine what area of the decoration was activated, without this, it can't make use of the event and discard it.

So that may look like an X server bug at first sight, but of course this needs to be investigated further before drawing any conclusion.

I am attaching a simple test program in plain C that you can use to determine if the subwindow is set appropriately.

Save the attachment as subwindow-field.c and compile it with:
$ gcc -o subwindow-field $(pkg-config --cflags --libs x11)
subwindow-field.c

(Note you'll need to have the developpment packages installed to be able to compile and link the test program)

Then, once build run the test prog with:
$ ./subwindow-field
and click in the large black window, using either your mouse/touchpad or the touchscreen.

If all is well, each time you click in the black window, you should see:
*** SUCCESS *** Subwindow is set
If you see:
*** FAILURE *** Subwindow is not set
Then this is most likely a bug in the X server.

Installed xorg-dev, and many input dev packages until i feared making too much of a mess. Still, the test program can't compile. The output:

$ gcc -o subwindow-field $(pkg-config --cflags --libs x11) subwindow-field.c /tmp/ccD6xeeR.o: In function main': subwindow-field.c:(.text+0x2c): undefined reference to XOpenDisplay' subwindow-field.c:(.text+0x127): undefined reference to XCreateSimpleWindow' subwindow-field.c:(.text+0x177): undefined reference to XCreateSimpleWindow' subwindow-field.c:(.text+0x197): undefined reference to XSelectInput' subwindow-field.c:(.text+0x1ab): undefined reference to XMapWindow' subwindow-field.c:(.text+0x1bf): undefined reference to XMapWindow' subwindow-field.c:(.text+0x1d6): undefined reference to XNextEvent' collect2: ld devolvió el estado de salida 1

What am i missing?

Gorsh said:

(Sorry for the double post)

Olivier Fourdan @olivier said:

I am not using the same distribution as you so I cannot really help you, but xorg-dev and input packages do not seem appropriate, what you need is libX11-dev or similar.

Gorsh said:

libx11-dev is already installed; more than that, all the necessary headers are in the system. stdio.h, unistd.h, stdlib.h and string.h are at /usr/include; stdarg.h is at /usr/lib/gcc/i686-linux-gnu/4.6.3/include; and Xlib.h and Xutil.h are at /usr/include/X11 as expected.

I even tried using absolute paths in their "#include < >" so to acount for any possible differences in their location - although i don't know if doing so is within the proper syntax of a C program. Also tried deleting one of the two calls to Xutil.h, just in case repeating them wasn't deliberate (just guessing here), and a few more tests found googling for the same compiling error (adding -lX11 as an option to the command, for example), but that was just random shots, without me understanding fully what i was doing.

Xlib.h has the "problematic" functions in it, of course. I'm blank now... ¿Any other non-compiling test method?

Olivier Fourdan @olivier said:

It's a linkage problem, not a compilation issue.

what gives "pkg-config --cflags --libs x11" ?

Would the following work better?

gcc subwindow-field.c -o subwindow-field $(pkg-config --cflags --libs x11)

Gorsh said:

(In reply to comment 8)

It's a linkage problem, not a compilation issue.

what gives "pkg-config --cflags --libs x11" ?

Would the following work better?

gcc subwindow-field.c -o subwindow-field $(pkg-config --cflags --libs x11)

Just to know, pkg... gave me just "-lX11"

But anyway, the new command worked to compile/link... Executed the file, touched the black window, and indeed i got:

ButtonPress 1 received in window 0x3a00001, subwindow 0x0 *** FAILURE *** Subwindow is not set

So it seems it is an X server bug in the end. I know this means it's not Xfwm4's bug anymore, but can you give me any pointers as to how to report/search for it in Xorg's bug tracker?

Olivier Fourdan @olivier said:

What's the driver used for this device? Could you attach the Xorg logs?

Gorsh uploaded an attachment:

Attachment 4643, "Xorg log":
Xorg.0.log

Gorsh said:

The touchscreen seems to be handled by evdev, as it reads from the log I attached...

AsusTek, Inc. MultiTouch: Applying InputClass "evdev touchscreen catchall" [ 26.389] (II) Using input driver 'evdev' for 'AsusTek, Inc. MultiTouch' [ 26.389] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so

I've tried some alternatives, but -this problem aside- this has been the most stable (tslib crashes as soon as i touch it, for example).

Evgeniy said:

Hi! I have this problem to on my Lenovo Yoga 13. I run subwindow-field test app (in GNOME 3.8), i see: *** FAILURE *** Subwindow is not set if touch by touchscreen.

Peter F. Patel-Schneider said:

I also have this problem on my Yoga 2 Pro under Fedora 20.

I agree that the problem is likely some weird interaction between how the touchscreen events are created and how xfwm interprets them. However, every other touchscreen event is handled properly so the problem is unique to xfwm.

I'll try to do some debugging with xev to see if there are any observable difference between touchscreen and touchpad events in the window title area.

Evgeniy said:

(In reply to Peter F. Patel-Schneider from comment 14)

I also have this problem on my Yoga 2 Pro under Fedora 20.

I agree that the problem is likely some weird interaction between how the touchscreen events are created and how xfwm interprets them. However, every other touchscreen event is handled properly so the problem is unique to xfwm.

I'll try to do some debugging with xev to see if there are any observable difference between touchscreen and touchpad events in the window title area.

I found a temporary solution here - http://xfce.10915.n7.nabble.com/Re-Xfwm-window-borders-do-not-respond-to-touch-screen-td42357.html

Peter F. Patel-Schneider said:

The solution pointed to by Evgeniy in Comment 15 does the trick. I suggest that it be added as a patch (if it doesn't break other things).

peter

alex said:

This has not been fixed yet, I unfortunately I don't have time or knowlage to compile Xfwm4 with the mentionen patch, http://xfce.10915.n7.nabble.com/Re-Xfwm-window-borders-do-not-respond-to-touch-screen-td42357.html

crysman said:

I am experiencing the same problem on Lenovo Ideapad S210 Touch. Unable to activate any of "minimize", "maximize" or "close" buttons on windows. I am able to move them by dragging when I drag them a little below the edge, though. Tested on newest Xubuntu (14.10), fresh install.

In "mouse and touchpad" settings I have "ELAN Touchscreen" listed. Any fix planned? I mean no patch (to recompile), but standard software update...

Thanks a lot.

Olivier Fourdan @olivier said:

Apparently not a bug in xfwm4:

http://lists.x.org/archives/xorg/2013-October/056118.html

crysman said:

So it's probably a bug in X - OK, but what is going to happen about it? :/

Olivier Fourdan @olivier said:

(In reply to crysman from comment 20)

So it's probably a bug in X

Here:

https://bugs.freedesktop.org/show_bug.cgi?id=70790

OK, but what is going to happen about it? :/

Well, the bug will be fixed eventually, then included in a later version of the X server and all will be fine.

added 5. Window Moving / Dragging 5. Window Resizing 5. Window Titlebar labels

Window borders do not respond to touchscreen

Submitted by Gorsh

Description

Designs

Child items ...

Activity

gcc -o subwindow-field $(pkg-config --cflags --libs x11) subwindow-field.c