github-starred/barrier

Fork 0

mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 14:16:02 -06:00

[GH-ISSUE #859] I can't use a touchscreen to control my client computer #684

New issue

Open

opened 2026-05-05 06:55:43 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 06:55:43 -06:00

Owner

Originally created by @Username-Is-Unavailabl on GitHub (Aug 30, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/859

Server: Zorin OS 15.2

Client: Windows 10 2004

Barrier Version

2.3.3

Steps to reproduce bug

1.Use a 2in1 laptop with touchscreen as server and a pc as client.
2.Start barrier on both of them.
3.After they connect,try using the touchscreen of the server 2in1 to control the client.
4.The cursor will move around at a very high speed,clicking random things and going out of view,but only on the client pc.

Other info

When did the problem start to occur? When I started using the touchscreen on the server.
Is there a way to work around it?No,I haven't found a way.
Does this bug prevent you from using Barrier entirely? Yes,it makes the touchscreen impossible to use with the client pc.
I want to be able to use the touchscreen on my 2in1 as a mouse to draw on my other laptop.

I have tried doing this with a remote desktop program and it worked perfectly fine,but i don't want to have to stream the entire screen of my laptop and I tought a software kvm will use less bandwith and have less latency.

Originally created by @Username-Is-Unavailabl on GitHub (Aug 30, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/859 Server: Zorin OS 15.2 Client: Windows 10 2004 ### Barrier Version ### 2.3.3 ### Steps to reproduce bug ### 1.Use a 2in1 laptop with touchscreen as server and a pc as client. 2.Start barrier on both of them. 3.After they connect,try using the touchscreen of the server 2in1 to control the client. 4.The cursor will move around at a very high speed,clicking random things and going out of view,but only on the client pc. ### Other info ### * When did the problem start to occur? When I started using the touchscreen on the server. * Is there a way to work around it?No,I haven't found a way. * Does this bug prevent you from using Barrier entirely? Yes,it makes the touchscreen impossible to use with the client pc. I want to be able to use the touchscreen on my 2in1 as a mouse to draw on my other laptop. I have tried doing this with a remote desktop program and it worked perfectly fine,but i don't want to have to stream the entire screen of my laptop and I tought a software kvm will use less bandwith and have less latency.

gitea-mirror added the

labels 2026-05-05 06:55:43 -06:00

gitea-mirror commented

2026-05-05 06:55:45 -06:00

Author

Owner

@shymega commented on GitHub (Aug 31, 2020):

Thanks for reporting this.

I'm not quite sure what's going on here - which PC runs Windows/Zorin, and which laptop runs Windows/Zorn? Cheers.

@shymega commented on GitHub (Aug 31, 2020): Thanks for reporting this. I'm not _quite_ sure what's going on here - which PC runs Windows/Zorin, and which laptop runs Windows/Zorn? Cheers.

gitea-mirror commented

2026-05-05 06:55:47 -06:00

Author

Owner

@Username-Is-Unavailabl commented on GitHub (Aug 31, 2020):

The server is a 2in1 laptop with touchscreen(asus transformer book t100ta), running Zorin OS 15.2(basically Ubuntu).
The client is a windows laptop(hp pavilion gaming 15-ecxxxx...),also in the main post, sometimes, I referred to it as a pc.
Also what I would like to be able to is use the touchscreen to control only the client and not be able to go back with the mouse to the server.
Let me explain a bit more what I want to do and why:
School is starting soon, and it will probably be on Zoom, and I want to be able to write on the touchscreen(using a pen that works on it) as if it was a real whiteboard(I am a teacher) as I it is much easier for me to write by hand than by keyboard or mouse.
Right now I am trying to use Windows Remote Desktop, TeamViewer or something that has low latency and works on LAN
Sorry for confusion, and thank you for help!

@Username-Is-Unavailabl commented on GitHub (Aug 31, 2020): The server is a 2in1 laptop with touchscreen(asus transformer book t100ta), running Zorin OS 15.2(basically Ubuntu). The client is a windows laptop(hp pavilion gaming 15-ecxxxx...),also in the main post, sometimes, I referred to it as a pc. Also what I would like to be able to is use the touchscreen to control **only** the client and not be able to go back with the mouse to the server. Let me explain a bit more what I want to do and why: School is starting soon, and it will probably be on Zoom, and I want to be able to write on the touchscreen(using a pen that works on it) as if it was a real whiteboard(I am a teacher) as I it is much easier for me to write by hand than by keyboard or mouse. Right now I am trying to use Windows Remote Desktop, TeamViewer or something that has low latency and works on LAN Sorry for confusion, and thank you for help!

gitea-mirror commented

2026-05-05 06:55:50 -06:00

Author

Owner

@florianhofhammer commented on GitHub (Sep 2, 2020):

I am working on a similar issue in #841 which was partly caused by me also observing this behavior on GNU/Linux machines with X11.
My changes include switching to the device where a touch input is detected so that the expected behavior (mouse cursor located at the position of the touch input) is achieved. The changes include the necessary code in the platform independent server and client code. However, I so far was only focusing on the X11 implementation and there might be some changes necessary to support windows devices also (i.e. trigger the corresponding event to this fix in src/lib/platform/MSWindowsScreen.cpp).

I unfortunately do not have access to devices with touch input anymore and thus cannot test any fixes. However, I'll look into it when I work on the changes requested to my PR #841 and let you know if I need help working on this issue and if yes, to what extent.

As I described above, the behavior I implemented was that the cursor in such a case jumps back to the server. I guess the behavior you're looking for is harder to achieve because some questions arise, e.g. how to behave if the screen resolutions differ and the movement vector on the server cannot be easily transformed to a movement vector on the client.
I'd love to hear some opinions on that!

@florianhofhammer commented on GitHub (Sep 2, 2020): I am working on a similar issue in #841 which was partly caused by me also observing this behavior on GNU/Linux machines with X11. My changes include switching to the device where a touch input is detected so that the expected behavior (mouse cursor located at the position of the touch input) is achieved. The changes include the necessary code in the platform independent server and client code. However, I so far was only focusing on the X11 implementation and there might be some changes necessary to support windows devices also (i.e. trigger the corresponding event to this fix in `src/lib/platform/MSWindowsScreen.cpp`). I unfortunately do not have access to devices with touch input anymore and thus cannot test any fixes. However, I'll look into it when I work on the changes requested to my PR #841 and let you know if I need help working on this issue and if yes, to what extent. As I described above, the behavior I implemented was that the cursor in such a case jumps back to the server. I guess the behavior you're looking for is harder to achieve because some questions arise, e.g. how to behave if the screen resolutions differ and the movement vector on the server cannot be easily transformed to a movement vector on the client. I'd love to hear some opinions on that!

No labels

Rows
Columns