I'm running Xubuntu 12.04.1 LTS on an Asus T91MT "netvertible"; it uses a propietary mutitouch touchscreen. The "Mouse & Touchpad" settings in Xfce lists it as "Asustek, Inc. MultiTouch". The touchscreen is fully working in all sorts of usages, even the multitouch gestures; but i can't "touch" the window borders in any way (moving, double-clicking, clicking on the buttons to close/maximize/etc.). 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.
Also: trying Xubuntu 12.10 Alpha 3 (Xfce 4.10) had the same behaviour.
Created attachment 4641 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.
Note: possible dupe of bug #9099
(In reply to comment #2) > Created attachment 4641 > 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 > 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?
(Sorry for the double post)
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.
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?
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)
(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?
What's the driver used for this device? Could you attach the Xorg logs?
Created attachment 4643 Xorg log
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).
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.
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.
(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
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
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
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.
Apparently not a bug in xfwm4: http://lists.x.org/archives/xorg/2013-October/056118.html
So it's probably a bug in X - OK, but what is going to happen about it? :/
(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.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/93. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev