wlfreerdp for weston , mouse wrong position after clicking #6722

Kimcn · 2021-01-18T08:00:54Z

I run wlfreerdp in Wayland>weston environment.
wlfreerdp /v /u /p /f /network:auto /gfx:avc444
When I open a folder, run a program, or minimize a window, The actual position of the mouse is about a certain distance below and to the right of the pointer, which makes it impossible to use the mouse accurately. When I move the mouse to the corner, the offset will disappear. I repeat the above to open the file and the problem will occur again.

Changed the system release version and freerdp version, and also used the night build version. The problem remains

akallabeth · 2021-01-18T09:08:39Z

can not reproduce, please add some more details.
(e.g. what are you connecting to?)
tried here against a windows 10 machine.

Kimcn · 2021-01-21T06:28:50Z

I use WLFREERDP to connect to server2019
The following is the video when the fault occurred, please help me
https://www.youtube.com/watch?v=6E1vUudhqYc

akallabeth · 2021-01-21T07:28:58Z

@Kimcn sorry, video not available?
As for information, server2019 is a good start.
but what are you running? (yes, weston and wlfreerdp but versions, specifically os and weston.
also, which build are you using? (self compiled/nightlies/...)

Kimcn · 2021-01-21T07:54:37Z

I use debian freerdp2-wayland:2.2.0 , weston:9.0
Just re-uploaded
https://www.youtube.com/watch?v=dt-FlM39I9w

akallabeth · 2021-01-21T08:17:48Z

@Kimcn could you retry with our nightlies https://github.com/FreeRDP/FreeRDP/wiki/PreBuilds and check if that has been fixed?

Kimcn · 2021-01-21T08:19:30Z

Ok I testing thanks

Kimcn · 2021-01-22T11:49:58Z

@akallabeth Still having the same problem I need help thanks
There was no wlfreerdp at night, so I extracted the latest code and recompiled
Parameters
cmake -GNinja -DCHANNEL_URBDRC = ON -DWITH_DSP_FFMPEG = ON -DWITH_CUPS = ON -DWITH_PULSE = ON -DWITH_FAAC = ON -DWITH_FAAD2 = ON -DWITH_GSM = ON.
I open a txt file and the mouse automatically moves to the top left. After I move the mouse to the bottom left corner of the edge of the desktop it becomes normal. At this point I click on the selected cursor position and everything is fine. When I select a text and click on another position, the mouse has a problem. It moves itself to the upper left for a certain distance and I find that after selecting the text and holding down the left mouse button, I can see that the mouse moves to the upper left for a certain distance and then moves away again after releasing the mouse without any text selected. It will not do this.
I'm using armbian and I've tested the same problem on several versions, kernels, and hardwares. I suspect that I'm missing some library files and I don't have a solution for this problem.

akallabeth · 2021-01-25T08:56:46Z

@Kimcn ok, finally managed to reproduce.
strangely enough this only happens with weston and not any other wayland session (gnome, ...)

mjt0k · 2021-09-24T10:30:12Z

Just gave wlfreerdp a try (it fits in a very small - about 200Mb - usb image without X, which is very nice!) and found the mouse positioning issue there when connecting to Win10 RDP server. The same server but with xfreerdp works fine, - only the wlfreerdp is affected. The issues seems to be what is described there.

In my case it is slightly different however. Mouse cursor loses its position when moving over a window border - it jumps some pixels. The position can be re-syncronized back by moving cursor to the edge of the screen (I always run wlfreerdp in fullscreen mode) - it fixes itself when touching the border.

On regular gnome wayland session mouse is also broken but differently: the cursor drawn a bit higher than actual mouse position. Can it be the top panel under weston (the one with application icons and the date/time display on top of the screen)? This happens only in fullscreen mode (/f option) - in window mode things appears to be running fine (but under gnome in windows mode the window does not have title or border so one can't close it).

Currently running debian bullseye version of wlfreerdp (2.3.0+dfsg1-2), but can try some debugging/recompiling for sure.

D-Y-V · 2021-10-11T15:04:38Z

Same things. I confirm, mouse position is incorrect when run wlfreerdp. When runnung iside xweston, also incorrect. But same xfreerdp running nice.
Gentoo ebuild produse 2 binaries, wlfreerdp - for wayland, and xfreerdp - for legacy X.
Desktop: weston latest git version.

Environment:
gentoo, unstable ~amd64 branch,
Compiled with flags:
net-misc/freerdp-2.4.0:0/2::gentoo USE="alsa jpeg wayland -X -
cups -debug -doc -ffmpeg -gstreamer -openh264 -pulseaudio -server -smartcard -sy
stemd -test -usb -xinerama -xv" 0 KiB

$ weston-info

*** Please use wayland-info instead
*** weston-info is deprecated and will be removed in a future version

interface: 'wl_compositor', version: 4, name: 1
interface: 'wl_subcompositor', version: 1, name: 2
interface: 'wp_viewporter', version: 1, name: 3
interface: 'zxdg_output_manager_v1', version: 2, name: 4
xdg_output_v1
output: 18
name: 'VGA-1'
logical_x: 1366, logical_y: 0
logical_width: 1920, logical_height: 1080
xdg_output_v1
output: 17
name: 'LVDS-1'
logical_x: 0, logical_y: 0
logical_width: 1366, logical_height: 768
interface: 'wp_presentation', version: 1, name: 5
presentation clock id: 1 (CLOCK_MONOTONIC)
interface: 'zwp_relative_pointer_manager_v1', version: 1, name: 6
interface: 'zwp_pointer_constraints_v1', version: 1, name: 7
interface: 'zwp_input_timestamps_manager_v1', version: 1, name: 8
interface: 'wl_data_device_manager', version: 3, name: 9
interface: 'wl_shm', version: 1, name: 10
formats: 'XYUV'(0x56555958) 'YUYV'(0x56595559) 'NV12'(0x3231564e) 'YU12'(0x32315559) RGB565 XRGB8888 ARGB8888
interface: 'wl_drm', version: 2, name: 11
interface: 'wl_seat', version: 7, name: 12
name: default
capabilities: pointer keyboard
keyboard repeat rate: 40
keyboard repeat delay: 400
interface: 'zwp_linux_dmabuf_v1', version: 3, name: 13
formats:
'UYVY'(0x59565955), modifier: 0x0100000000000002
------------- LONG SKIP -------------------------------
'AB4H'(0x48344241), modifier: 0x0000000000000000
'AB4H'(0x48344241), modifier: 0x00ffffffffffffff
interface: 'weston_direct_display_v1', version: 1, name: 14
interface: 'zwp_linux_explicit_synchronization_v1', version: 2, name: 15
interface: 'weston_content_protection', version: 1, name: 16
interface: 'wl_output', version: 3, name: 17
x: 0, y: 0, scale: 1,
physical_width: 310 mm, physical_height: 170 mm,
make: 'AUO', model: 'unknown',
subpixel_orientation: horizontal rgb, output_transform: normal,
mode:
width: 1366 px, height: 768 px, refresh: 60.098 Hz,
flags: current preferred
interface: 'wl_output', version: 3, name: 18
x: 1366, y: 0, scale: 1,
physical_width: 530 mm, physical_height: 300 mm,
make: 'DEL', model: 'DELL S2440L',
subpixel_orientation: unknown, output_transform: normal,
mode:
width: 1920 px, height: 1080 px, refresh: 60.000 Hz,
flags: current preferred
mode:
width: 1280 px, height: 1024 px, refresh: 75.025 Hz,
flags:
mode:

interface: 'zwp_input_panel_v1', version: 1, name: 19
interface: 'zwp_input_method_v1', version: 1, name: 20
interface: 'zwp_text_input_manager_v1', version: 1, name: 21
interface: 'xdg_wm_base', version: 1, name: 22
interface: 'wl_shell', version: 1, name: 23
interface: 'weston_desktop_shell', version: 1, name: 24
interface: 'weston_screenshooter', version: 1, name: 25

2 displays. On both displays mouse have incorrect coordinates in wlfreerdp window.

With best wishes - Yuriy Dmitriev.

akallabeth · 2021-10-11T17:08:09Z

does weston draw a window bar with buttons on top? might be that these must be subtracted/added to the position, can´t reproduce here on my debian 11/gnome wayland setup. Only with weston.

D-Y-V · 2021-10-11T17:25:55Z

Hi) I make vido and post details after few min.11 окт. 2021 г. 20:08 пользователь akallabeth ***@***.***> написал: does weston draw a window bar with buttons on top? might be that these must be subtracted/added to the position, can´t reproduce here on my debian 11/gnome weston setup. —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.

D-Y-V · 2021-10-11T17:54:21Z

Please, see in detail.
https://svk.r117.com/VID_20211011_202754.mp4
Please, download for investigate. Video stored limited time.
With best wishes - YD.

UPD: Video size is aprox 508 Mb

mjt0k · 2021-10-11T18:22:51Z

it is a bit more interesting than a compensation for a menu bar. Initially wlfreerdp calculates everything correctly, what makes it lose syncronization is when a cursor is moved "off the screen" in the remote window. And the same move but at the opposite side of the "remote screen" makes it syncronize again

mjt0k · 2021-10-11T18:26:06Z

I guess this is a confusion between a work area size (which is smaller under weston indeed, due to the menu/application bar) and the local screen size in full-screen mode, where whole screen size should be used instead of the work area, since in full-screen mode we occupy whole screen not just the work area. But this is just my guess..

D-Y-V · 2021-10-11T18:51:46Z

May be. Too long ago, I play with wayland api. I rewrite for my own spice remote viewer. Rewrite I mean port from original gtk to wayland. And see same things if I realize incorrect input event loop and window decorations...

D-Y-V · 2021-10-11T18:57:11Z

I long time ago solve this via print to console x= y= mouse coord. It may help.

The function scale_signed_coordinates did use addresses instead of values

D-Y-V · 2021-10-14T13:31:45Z

Hi akallabeth!!! Thanks for correct some errors:)
But unfortunately, not fixed.
I tested on 2 separate machines. Notebook && Intel NUC.
Reopen please bug. Not all fixed. Some err still exists.

With best wishes - YD.

D-Y-V · 2021-10-14T13:34:10Z

$ wlfreerdp /buildconfig
This is FreeRDP version 3.0.0-dev (73fbbcf)
Build configuration: BUILD_TESTING=OFF BUILTIN_CHANNELS=ON HAVE_AIO_H=1 HAVE_EXECINFO_H=1 HAVE_FCNTL_H=1 HAVE_GETLOGIN_R=1 HAVE_INTTYPES_H=1 HAVE_M
ATH_C99_LONG_DOUBLE=1 HAVE_PIXMAN_REGION=OFF HAVE_POLL_H=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIB=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIBS= HAVE_PTHREAD_MUTEX
_TIMEDLOCK_SYMBOL=1 HAVE_STRNDUP=1 HAVE_SYSLOG_H=1 HAVE_SYS_EVENTFD_H=1 HAVE_SYS_FILIO_H= HAVE_SYS_SELECT_H=1 HAVE_SYS_SOCKIO_H= HAVE_SYS_TIMERFD_H
=1 HAVE_TM_GMTOFF=1 HAVE_UNISTD_H=1 WITH_ALSA=ON WITH_CAIRO=ON WITH_CCACHE=OFF WITH_CHANNELS=ON WITH_CLANG_FORMAT=ON WITH_CLIENT=ON WITH_CLIENT_AVA
ILABLE=1 WITH_CLIENT_CHANNELS=ON WITH_CLIENT_CHANNELS_AVAILABLE=1 WITH_CLIENT_COMMON=ON WITH_CLIENT_INTERFACE=OFF WITH_CUPS=OFF WITH_DEBUG_ALL=OFF
WITH_DEBUG_CAPABILITIES=OFF WITH_DEBUG_CERTIFICATE=OFF WITH_DEBUG_CHANNELS=OFF WITH_DEBUG_CLIPRDR=OFF WITH_DEBUG_DVC=OFF WITH_DEBUG_EVENTS=OFF WITH
DEBUG_KBD=OFF WITH_DEBUG_LICENSE=OFF WITH_DEBUG_MUTEX=OFF WITH_DEBUG_NEGO=OFF WITH_DEBUG_NLA=OFF WITH_DEBUG_NTLM=OFF WITH_DEBUG_RAIL=OFF WITH_DEBU
G_RDP=OFF WITH_DEBUG_RDPDR=OFF WITH_DEBUG_RDPEI=OFF WITH_DEBUG_RDPGFX=OFF WITH_DEBUG_REDIR=OFF WITH_DEBUG_RFX=OFF WITH_DEBUG_RINGBUFFER=OFF WITH_DE
BUG_SCARD=OFF WITH_DEBUG_SND=OFF WITH_DEBUG_SVC=OFF WITH_DEBUG_SYMBOLS=OFF WITH_DEBUG_THREADS=OFF WITH_DEBUG_TIMEZONE=OFF WITH_DEBUG_TRANSPORT=OFF
WITH_DEBUG_TSG=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF_AVAILABLE=0 WITH_DEBUG_WND=OFF WITH_DEBUG_X11=OFF WITH_DEBUG_X11_CLIPRDR=OFF WITH_DEBUG_X11
LOCAL_MOVESIZE=OFF WITH_DEBUG_XV=OFF WITH_DSP_EXPERIMENTAL=OFF WITH_DSP_FFMPEG=OFF WITH_EVENTFD_READ_WRITE=1 WITH_FAAC=OFF WITH_FAAD2=OFF WITH_FFMP
EG=OFF WITH_FREERDP_DEPRECATED=OFF WITH_GFX_H264=OFF WITH_GPROF=OFF WITH_GSM=OFF WITH_GSSAPI=OFF WITH_GSTREAMER_1_0=OFF WITH_ICU=OFF WITH_IPP=OFF W
ITH_JPEG=OFF WITH_LAME=OFF WITH_LIBRARY_VERSIONING=ON WITH_LIBSYSTEMD=OFF WITH_MACAUDIO=OFF WITH_MACAUDIO_AVAILABLE=0 WITH_MANPAGES=OFF WITH_MBEDTL
S=OFF WITH_NATIVE_SSPI=OFF WITH_NEON=OFF WITH_OPENCL=OFF WITH_OPENH264=OFF WITH_OPENSLES=OFF WITH_OPENSSL=ON WITH_OSS=ON WITH_PCSC=OFF WITH_PROFILE
R=OFF WITH_PULSE=OFF WITH_SAMPLE=OFF WITH_SANITIZE_ADDRESS=OFF WITH_SANITIZE_ADDRESS_AVAILABLE=1 WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY_AVAI
LABLE=1 WITH_SANITIZE_THREAD=OFF WITH_SANITIZE_THREAD_AVAILABLE=1 WITH_SERVER=OFF WITH_SERVER_INTERFACE=ON WITH_SMARTCARD_INSPECT=OFF WITH_SOXR=OFF
WITH_SSE2=ON WITH_SWSCALE=OFF WITH_THIRD_PARTY=OFF WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK_AVAILABLE=1 WITH_VERBOSE_WINPR_ASSERT=ON WITH
_WAYLAND=ON WITH_WINPR_DEPRECATED=OFF WITH_WINPR_TOOLS=ON WITH_X11=OFF WITH_XINERAMA=OFF WITH_XV=OFF WITH_ZLIB=ON
Build type: Gentoo
CFLAGS: -O2 -pipe -march=native -fPIC -Wall -fvisibility=hidden -Wimplicit-function-declaration -Wredundant-decls -g -fno-omit-frame-p
ointer
Compiler: GNU, 11.2.0
Target architecture: x64

akallabeth · 2021-10-14T13:38:09Z

@D-Y-V well, if you tell me which one is not fixed I repoen ;)

D-Y-V · 2021-10-14T13:46:03Z

Thanks, and I explain some new. I connect to windows machine. All seems like ok. After 3-5-7 sec mouse without my take, self slow move to UP. After this self-moving effect, I have incorrect mouse coordinates, like video, which I posted above. May be it help...
With best wishes - YD.

gregd72002 · 2022-11-02T23:13:15Z

Anyone tried the change from @gschwind to see if this also resolves issue in weston?

gregd72002 · 2022-11-03T22:15:47Z

Right, I've compiled latest freerdp with the change and still having the same issue. The alpha channel is now removed but the issue persists in Weston.

gregd72002 · 2022-11-13T20:57:02Z

No idea where the problem is but the following seems to work:

--- uwac/libuwac/uwac-input.c.orig	2022-11-13 20:55:27.425539318 +0000
+++ uwac/libuwac/uwac-input.c	2022-11-13 20:55:38.955400389 +0000
@@ -1141,8 +1141,8 @@
 			return UWAC_ERROR_NOMEMORY;
 		seat->pointer_image->width = width;
 		seat->pointer_image->height = height;
-		seat->pointer_image->hotspot_x = hot_x;
-		seat->pointer_image->hotspot_y = hot_y;
+		//seat->pointer_image->hotspot_x = hot_x;
+		//seat->pointer_image->hotspot_y = hot_y;
 
 		free(seat->pointer_data);
 		seat->pointer_data = xmalloc(length);

akallabeth · 2022-11-14T06:56:27Z

@gregd72002 ok, interesting. you mind debugging which values of hot_x and hot_y you get when the problem occurs?

gschwind · 2022-11-14T08:52:48Z

Hello @akallabeth and @gregd72002

I did the following code here to debug/understand what going on with the cursor. The code is only durty code for debug purpose and may not work for you. As you can see on the screenshot attached the patch do draw the position where the cursor is according wlfreerdp in blue. I also modify the cursor texture by drawing it's borders in green and the expected hot point in red. As you can see in my case every thing is in good shape without any positioning error. If I enable the alpha with 2x scale I get the cursor will be with half size in both direction, and the hot point in red is not any more consistent with the blue lines.

gregd72002 · 2022-11-14T09:32:26Z

@gregd72002 ok, interesting. you mind debugging which values of hot_x and hot_y you get when the problem occurs?

Here it is. I've added this line just before the return:

fprintf(stdout, "%s: x:%u y:%u t:%u \n", __func__, hot_x, hot_y, seat->pointer_type);

The function is triggered only in certain situations. I could not make quite sense when exactly. But I did not spend much time on it either. It felt like it is triggered when the cursor leaves/reenters the screen or passes certain screen windows.

Also something I noticed earlier, when I was experiencing the problems with the cursor position, when I clicked left mouse button and kept it pressed in, I could move the cursor freely and the mouse cursor position was all the time in sync.

[20:52:33:782] [1306:1306] [WARN][com.freerdp.core.nego] - Error: SSL_NOT_ALLOWED_BY_SERVER
[20:52:33:792] [1306:1306] [WARN][com.freerdp.core.nego] - Error: SSL_NOT_ALLOWED_BY_SERVER
[20:52:34:908] [1306:1306] [INFO][com.freerdp.gdi] - Local framebuffer format  PIXEL_FORMAT_BGRA32
[20:52:34:908] [1306:1306] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_BGRA32
[20:52:34:995] [1306:1306] [INFO][com.freerdp.channels.rdpsnd.client] - [static] Loaded fake backend for rdpsnd
[20:52:34:995] [1306:1306] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel rdpgfx
UwacSeatSetMouseCursor: x:0 y:0 t:1 
UwacSeatSetMouseCursor: x:16 y:16 t:2 
UwacSeatSetMouseCursor: x:16 y:16 t:2 
UwacSeatSetMouseCursor: x:16 y:16 t:2 
UwacSeatSetMouseCursor: x:0 y:0 t:2 
UwacSeatSetMouseCursor: x:0 y:0 t:2 
UwacSeatSetMouseCursor: x:4 y:11 t:2 
UwacSeatSetMouseCursor: x:0 y:0 t:2 
UwacSeatSetMouseCursor: x:4 y:11 t:2 
UwacSeatSetMouseCursor: x:0 y:0 t:2 
UwacSeatSetMouseCursor: x:4 y:11 t:2 
UwacSeatSetMouseCursor: x:0 y:0 t:2 
UwacSeatSetMouseCursor: x:4 y:11 t:2 
UwacSeatSetMouseCursor: x:0 y:0 t:2 
UwacSeatSetMouseCursor: x:9 y:9 t:2 
UwacSeatSetMouseCursor: x:0 y:0 t:2 
UwacSeatSetMouseCursor: x:4 y:11 t:2 
UwacSeatSetMouseCursor: x:0 y:0 t:2 
UwacSeatSetMouseCursor: x:4 y:11 t:2 
UwacSeatSetMouseCursor: x:0 y:0 t:2 
UwacSeatSetMouseCursor: x:4 y:11 t:2 
UwacSeatSetMouseCursor: x:0 y:0 t:2 
UwacSeatSetMouseCursor: x:4 y:11 t:2 
UwacSeatSetMouseCursor: x:0 y:0 t:2 
UwacSeatSetMouseCursor: x:4 y:11 t:2 
UwacSeatSetMouseCursor: x:0 y:0 t:2 
UwacSeatSetMouseCursor: x:4 y:11 t:2 
UwacSeatSetMouseCursor: x:0 y:0 t:2 
UwacSeatSetMouseCursor: x:9 y:9 t:2 
UwacSeatSetMouseCursor: x:0 y:0 t:2 
UwacSeatSetMouseCursor: x:4 y:11 t:2 
UwacSeatSetMouseCursor: x:0 y:0 t:2 
UwacSeatSetMouseCursor: x:6 y:0 t:2 
UwacSeatSetMouseCursor: x:0 y:0 t:2 
UwacSeatSetMouseCursor: x:4 y:11 t:2 
UwacSeatSetMouseCursor: x:0 y:0 t:2 
^[[A^C[20:53:42:462] [1306:1306] [ERROR][com.freerdp.utils] - Caught signal 'Interrupt' [2]

akallabeth · 2022-11-14T10:37:19Z

@gschwind could you clarify which 2x scale you are activating? Local HighDPI (e.g. gnome), RDP remote scaling?

gschwind · 2022-11-14T10:48:18Z

@akallabeth It's on the gnome side, the desktop use scale 200%, thus the window above is created with /w:800 /h:600 and appear on screen as 1600x1200 as within the screen shot. That why I filled a bug to gnome-shell/mutter. wlfreerdp always work as if the window is 800x600 as expected.

gschwind · 2022-11-14T10:50:33Z

Also note that in my case, wlfreerdp always use the cursor provided by the server and never use the default local cursor.

gschwind · 2022-11-14T11:11:38Z

I did more screenshot and first I trigger the issue you get (the one not related to alpha) as in the following screen shot, where the server side highlight the close button and the cursor is outside the window. This apply for other buttons, the cursor is quite far away from button while button appear highlighted,

gschwind · 2022-11-14T11:22:37Z

I have issue with screen shot that fix the alpha issue. What I get with screenshot:

And what I see taken with my phone:

We can see here that on screen the cursor is not scaled properly, and scale it twice should fix the issue. We can also see that blue line are 2 pixels large as expected, but the cursor red lines are 1 pixel large.

akallabeth · 2022-11-14T11:59:18Z

@gschwind thanks, that helps. so, you only set gnome scaling, and no /smart-sizing or /scale options of FreeRDP?
[edit] edited, missed the post above

gschwind · 2022-11-14T12:41:55Z

@akallabeth The scale is perfomed by the compositor. wlfreerdp is not aware of the scale directly, I use the following command: ./build/client/Wayland/wlfreerdp /w:800 /h:600 /u:xxxx /v:yyyyy

gschwind · 2022-11-14T12:52:58Z

Also note that in my case the sever side is the xrdp server. I think the server is using freerdp.

akallabeth · 2022-11-14T15:13:11Z

@gschwind ok, so this confirms the issue is not in freerdp.
If you don´t use any /scale* or /smart-sizing options everything needs to be scaled by the compositor and there seems to be some bug there.
On a side note, I´ve encountered similar issues with libreoffice flathub/org.libreoffice.LibreOffice#199 which seems to be some kind of build issue. Maybe that helps (or not, don´t know)

gschwind · 2022-11-14T15:15:50Z

Hello, I did another test with a test program at the server side. And the server side get seems to have the correct cursor position. In the following photo taken with my phone, we can see the dot blue line matching the purple line drawn within the test window.

gregd72002 · 2022-11-14T20:14:15Z

it sounds like there are 2 different bugs in here. I'm not using Gnome nor any scaling whatsoever and had the issue that the local cursor position was not in sync with the remote cursor

gschwind · 2022-11-14T23:00:46Z

Hello,

I suspect this line :

FreeRDP/uwac/libuwac/uwac-input.c

Line 137 in 8760cec

wl_surface_attach(surface, buffer, -x, -y);

to be the guilty, but under gnome the offset here (-x, -y) is ignored, if I change it to 0,0 it does not change anything, but according to the spec:

On surface.attach requests to the pointer surface, hotspot_x and hotspot_y are decremented by the x and y parameters passed to the request. Attach must be confirmed by wl_surface.commit as usual.

Thus as far as understand offset should be zero in our case.

akallabeth · 2022-11-15T06:57:46Z

@gschwind no, the mouse pointer has an image that is not necessarily aligned to its upper left corner. The hotspot x and y offset tells where that upper left corner is

gschwind · 2022-11-15T08:45:37Z

@akallabeth I know but if you read the full spec the positioning of the cursor, the position of the texture is relative to his hot-point [1] and you do not need to attach it with an offset. Maybe for older version it was necessary, but know the spec require a different setting. And if it required by an older spec, maybe we need a fix that take care of protocol versions. The related text within the specification:

The parameters hotspot_x and hotspot_y define the position of the pointer surface relative to the pointer location. Its top-left corner is always at (x, y) - (hotspot_x, hotspot_y), where (x, y) are the coordinates of the pointer location, in surface-local coordinates.

[1] https://wayland.app/protocols/wayland#wl_pointer:request:set_cursor

gschwind · 2022-11-17T07:29:43Z

@D-Y-V can you try the last master, maybe #8411 solved you issue.

The gnome issue with alpha is WIP

mjt0k · 2022-12-30T08:42:11Z

https://gitlab.freedesktop.org/wayland/weston/-/commits/10.0.3/ - commits in 10.0.3 in weston addresses this very issue. With 10.0.3, or current 11.0.[01], the mouse cursor position in wlfreerdp is now stable.

But there, wlfreerdp has a new set of issues - eg, big mishandling of (offscreen?) bitmaps, huge flickering of everything during plain mouse move, and many others..

akallabeth · 2022-12-30T09:36:59Z

@MichaelJTokarev the flickering is another issue, but if the mouse is working now it might be time to start fixing the other issues in wlfreerdp as well :)

ManMower · 2023-01-13T19:30:08Z

We discussed this on the weston IRC channel earlier today, and I'll recap the findings here so they're not lost.

Part of the problem has been fixed, the incorrect attach parameters.

What's left is because the freerdp client is using incorrect serials in the wl_pointer_set_cursor() call. As stated in the wayland protocol documentation at https://gitlab.freedesktop.org/wayland/wayland/-/blob/master/protocol/wayland.xml#L1909 wl_pointer_set_cursor() should be passed the serial of the enter event.

However, uwac-input.c updates the serial number on many other events (touch, keystroke, click). So when any of these events occur, the serial number will be broken until the next time the pointer leaves and reenters the window, so updating the cursor won't work correctly until that occurs.

I think the fix is just removing all the seat->display->serial = serial; assignments that aren't driven by the pointer enter event, since display->serial appears to only be used for cursor setting.

akallabeth · 2023-01-13T20:20:45Z

@ManMower @MichaelJTokarev looks like that patch was already upstreamed to master but not yet backported to stable. Done that with #8612

ManMower · 2023-01-13T20:42:13Z

@ManMower @MichaelJTokarev looks like that patch was already upstreamed to master but not yet backported to stable. Done that with #8612

Nice, those fixes look correct to me!

akallabeth added the waiting-feedback label Jan 18, 2021

akallabeth added client help-wanted wayland and removed waiting-feedback labels Jan 25, 2021

akallabeth added this to the next milestone Oct 14, 2021

akallabeth added a commit to akallabeth/FreeRDP that referenced this issue Oct 14, 2021

Fixed FreeRDP#6722: Wayland client mouse coordinates

1a8b19c

The function scale_signed_coordinates did use addresses instead of values

akallabeth added the fixed-waiting-test label Oct 14, 2021

akallabeth closed this as completed in 6ea5823 Oct 14, 2021

akallabeth modified the milestones: next-3.0, stable-next Jan 13, 2023

akallabeth linked a pull request Jan 13, 2023 that will close this issue

uwac/input: Set the right serial when setting cursor #8612

Merged

akallabeth closed this as completed Jan 14, 2023

wlfreerdp for weston , mouse wrong position after clicking #6722

wlfreerdp for weston , mouse wrong position after clicking #6722

Comments

Kimcn commented Jan 18, 2021 • edited

akallabeth commented Jan 18, 2021

Kimcn commented Jan 21, 2021 • edited

akallabeth commented Jan 21, 2021

Kimcn commented Jan 21, 2021 • edited

akallabeth commented Jan 21, 2021

Kimcn commented Jan 21, 2021

Kimcn commented Jan 22, 2021

akallabeth commented Jan 25, 2021

mjt0k commented Sep 24, 2021 • edited

D-Y-V commented Oct 11, 2021

akallabeth commented Oct 11, 2021 • edited

D-Y-V commented Oct 11, 2021 via email

D-Y-V commented Oct 11, 2021 • edited

mjt0k commented Oct 11, 2021

mjt0k commented Oct 11, 2021

D-Y-V commented Oct 11, 2021

D-Y-V commented Oct 11, 2021

D-Y-V commented Oct 14, 2021

D-Y-V commented Oct 14, 2021

akallabeth commented Oct 14, 2021

D-Y-V commented Oct 14, 2021

gregd72002 commented Nov 2, 2022

gregd72002 commented Nov 3, 2022 • edited

gregd72002 commented Nov 13, 2022 • edited

akallabeth commented Nov 14, 2022

gschwind commented Nov 14, 2022 • edited

gregd72002 commented Nov 14, 2022 • edited

akallabeth commented Nov 14, 2022

gschwind commented Nov 14, 2022

gschwind commented Nov 14, 2022

gschwind commented Nov 14, 2022

gschwind commented Nov 14, 2022

akallabeth commented Nov 14, 2022 • edited

gschwind commented Nov 14, 2022 • edited

gschwind commented Nov 14, 2022 • edited

akallabeth commented Nov 14, 2022

gschwind commented Nov 14, 2022

gregd72002 commented Nov 14, 2022

gschwind commented Nov 14, 2022

akallabeth commented Nov 15, 2022

gschwind commented Nov 15, 2022

gschwind commented Nov 17, 2022

mjt0k commented Dec 30, 2022

akallabeth commented Dec 30, 2022

ManMower commented Jan 13, 2023

akallabeth commented Jan 13, 2023

ManMower commented Jan 13, 2023

Kimcn commented Jan 18, 2021 •

edited

Kimcn commented Jan 21, 2021 •

edited

Kimcn commented Jan 21, 2021 •

edited

mjt0k commented Sep 24, 2021 •

edited

akallabeth commented Oct 11, 2021 •

edited

D-Y-V commented Oct 11, 2021 •

edited

gregd72002 commented Nov 3, 2022 •

edited

gregd72002 commented Nov 13, 2022 •

edited

gschwind commented Nov 14, 2022 •

edited

gregd72002 commented Nov 14, 2022 •

edited

akallabeth commented Nov 14, 2022 •

edited

gschwind commented Nov 14, 2022 •

edited

gschwind commented Nov 14, 2022 •

edited