Mobile UI expirience

deekerman commented

2026-02-20 14:10:57 -05:00

Owner

Originally created by @mdevaev on GitHub (Nov 26, 2025).

Originally assigned to: @mdevaev on GitHub.

This is a cumulative tissue for your feedback for the PiKVM mobile Web UI. The topic will describe various features include proposed by users, and in the comments you can suggest your own ones concerning the basic aspects of using PiKVM on mobile devices.

If your problem has nothing to do with interface design or it's just a bug, please create a new issue.

Please note that right now our efforts are focused on tablets. Discussions and ideas for phones are welcome, but so far we have no certain plans to improve the UI on very small screens.

Applied features:

Fullscreen mode with quick access to navbar: both on mobile and desktop UI.
Floating panel for mouse buttons.
Gesture: two-finger scrolling.
Gesture: touch to point absolute mouse.
Gesture: slide to move relative mouse.
Responsive mobile keyboard layout.
Current hold-to-lock mechanism is fine, we just need to make buttons bigger and use free space more efficient.
Pinch to zoom on mobile, view on 1:1 scale, and something similar for a desktop.
Merged because of similar purposes and implementation. The user says that 1:1 view is necessary if the target screen is very large and the browser screen is small. Also this is a typical mobile use-case. Should be possible in full-screen mode too.

Discussable:

Gesture: tap-to-click.
I'm inclined to not to implement this feature since in the case of an absolute mouse it is impossible to distinguish a click from cursor positioning. As an alternative, we have a floating panel with mouse buttons. Should we make a floating pointer, like on Jump VNC?
Precise touch(slide?)-to-point.
My experience using the latest PiKVM UI on a iPad shows that this is not necessary.
Phone-optimized UI.
I don't know how to make it with our current layout.
Virtual Keyboard for Webterm.
Subj. Maybe something like mobile-oriented terminal would be useful too.

Originally created by @mdevaev on GitHub (Nov 26, 2025). Originally assigned to: @mdevaev on GitHub. This is a cumulative tissue for your feedback for the PiKVM mobile Web UI. The topic will describe various features include proposed by users, and in the comments you can suggest your own ones concerning the basic aspects of using PiKVM on mobile devices. **If your problem has nothing to do with interface design or it's just a bug, please create a new issue.** Please note that **right now our efforts are focused on tablets**. Discussions and ideas for phones are welcome, but so far we have no certain plans to improve the UI on very small screens. Applied features: - [x] Fullscreen mode with quick access to navbar: both on mobile and desktop UI. - [x] Floating panel for mouse buttons. - [x] Gesture: two-finger scrolling. - [x] Gesture: touch to point absolute mouse. - [x] Gesture: slide to move relative mouse. - [ ] Responsive mobile keyboard layout. *Current hold-to-lock mechanism is fine, we just need to make [buttons bigger](https://github.com/pikvm/pikvm/issues/1531) and use free space more efficient.* - [ ] Pinch to zoom on mobile, view on 1:1 scale, and something similar for a desktop. *Merged because of similar purposes and implementation. The user [says](https://github.com/pikvm/pikvm/issues/1322) that 1:1 view is necessary if the target screen is very large and the browser screen is small. Also this is a [typical](https://github.com/pikvm/pikvm/issues/1534) mobile use-case. Should be possible in full-screen mode too.* Discussable: - [ ] Gesture: tap-to-click. *I'm inclined to not to implement this feature since in the case of an absolute mouse it is impossible to distinguish a click from cursor positioning. As an alternative, we have a floating panel with mouse buttons. Should we make a floating pointer, like on Jump VNC?* - [ ] Precise touch(slide?)-to-point. *My experience using the latest PiKVM UI on a iPad shows that this is not necessary.* - [ ] Phone-optimized UI. *I don't know how to make it with our current layout.* - [ ] Virtual Keyboard for Webterm. *Subj. Maybe something like mobile-oriented terminal would be useful too.*

deekerman added the

type:feature

label

2026-02-20 14:10:57 -05:00

deekerman commented

2026-02-20 14:10:59 -05:00

Author

Owner

@devildant commented on GitHub (Nov 29, 2025):

Hi,

Ideally, it should be possible to zoom on the screen without zooming the entire page. The keyboard should also look similar to the native mobile keyboard so that it can be used without needing to zoom in manually.
Here is the link to my prototype:
https://devildant.github.io/pikvm-windows-monitoring/

Here is the video showing how it looks on mobile:
https://github.com/user-attachments/assets/fdab2ea4-3167-4c01-af09-c0bb6a9cbf61

@devildant commented on GitHub (Nov 29, 2025): Hi, Ideally, it should be possible to zoom on the screen without zooming the entire page. The keyboard should also look similar to the native mobile keyboard so that it can be used without needing to zoom in manually. Here is the link to my prototype: https://devildant.github.io/pikvm-windows-monitoring/ Here is the video showing how it looks on mobile: https://github.com/user-attachments/assets/fdab2ea4-3167-4c01-af09-c0bb6a9cbf61

deekerman commented

2026-02-20 14:10:59 -05:00

Author

Owner

@matthewmgr commented on GitHub (Nov 29, 2025):

As an iPad user, who uses Bluetooth mouse, Apple Keyboard Folio, or something similar no "floating mouse" will be presented to them. Should any of these things disconnect (or the user choose to enable) the floating mouse should be docked somewhere accessible via touch.

@matthewmgr commented on GitHub (Nov 29, 2025): As an iPad user, who uses Bluetooth mouse, Apple Keyboard Folio, or something similar no "floating mouse" will be presented to them. Should any of these things disconnect (or the user choose to enable) the floating mouse should be docked somewhere accessible via touch.

deekerman commented

2026-02-20 14:10:59 -05:00

Author

Owner

@medicalwei commented on GitHub (Dec 1, 2025):

Hi, I am facing a similar problem as @matthewmgr mentioned, that the window for mouse buttons cannot be hidden. I am wondering whether that's an intentional choice so the keyboard and top bar (in full screen) is reachable.

As for keyboard, the keyboard on the phone is too small to press (even on a 5.5" phone). Maybe mimicking mobile keyboard and layering symbols and Fn keys should be fine for normal typing.

@medicalwei commented on GitHub (Dec 1, 2025): Hi, I am facing a similar problem as @matthewmgr mentioned, that the window for mouse buttons cannot be hidden. I am wondering whether that's an intentional choice so the keyboard and top bar (in full screen) is reachable. As for keyboard, the keyboard on the phone is too small to press (even on a 5.5" phone). Maybe mimicking mobile keyboard and layering symbols and Fn keys should be fine for normal typing.

deekerman commented

2026-02-20 14:10:59 -05:00

Author

Owner

@mdevaev commented on GitHub (Dec 1, 2025):

@medicalwei The idea is that the floating panel gives access to the mouse buttons, the top panel call button, and the keyboard. Why do you want to hide it on your phone?

@mdevaev commented on GitHub (Dec 1, 2025): @medicalwei The idea is that the floating panel gives access to the mouse buttons, the top panel call button, and the keyboard. Why do you want to hide it on your phone?

deekerman commented

2026-02-20 14:10:59 -05:00

Author

Owner

@medicalwei commented on GitHub (Dec 1, 2025):

Why do you want to hide it on your phone?

The problem is that I am using iPad with a keyboard+touchpad case, which renders mouse buttons redundant.

However, the top panel call button is probably still necessary. It could be made able to be minimized, semi transparent and draggable. For example on the Windows (RDP) app:

@medicalwei commented on GitHub (Dec 1, 2025): > Why do you want to hide it on your phone? The problem is that I am using iPad with a keyboard+touchpad case, which renders mouse buttons redundant. However, the top panel call button is probably still necessary. It could be made able to be minimized, semi transparent and draggable. For example on the Windows (RDP) app: ![image](https://github.com/user-attachments/assets/d4d49a4d-112a-4811-ba65-e8b3bc7d3717)

deekerman commented

2026-02-20 14:10:59 -05:00

Author

Owner

@dm-vodopyanov commented on GitHub (Dec 1, 2025):

Thanks for the great boost to the iPad experience! My only concern is the same as mentioned above - I’m using a keyboard and a mouse with my iPad, and this floating panel kinda bothers me. The “three dots” button is the only part that’s really useful for my use case.
Maybe in the future this panel could be hidden with some hotkey? That way the streaming screen would be completely clean, and since it now supports full-screen mode, that would be very cool!

@dm-vodopyanov commented on GitHub (Dec 1, 2025): Thanks for the great boost to the iPad experience! My only concern is the same as mentioned above - I’m using a keyboard and a mouse with my iPad, and this floating panel kinda bothers me. The “three dots” button is the only part that’s really useful for my use case. Maybe in the future this panel could be hidden with some hotkey? That way the streaming screen would be completely clean, and since it now supports full-screen mode, that would be very cool!

deekerman commented

2026-02-20 14:10:59 -05:00

Author

Owner

@cRoCx commented on GitHub (Dec 1, 2025):

I have tested these new mobile UI features of this "issue" as well. I see this rather as a workaround than a solution for #1534 .
To me the touch input is still broken and doing two touches to simulate one click is rather annoying (1x touch to drag the mouse pointer there and then touching the floating mouse click panel to trigger the click).
My workaround is using both a VNC and a WebRTC connection at the same time... VNC for touch input and in the background WebRTC for all the other sweet and awesome features.

@cRoCx commented on GitHub (Dec 1, 2025): I have tested these new mobile UI features of this "issue" as well. I see this rather as a workaround than a solution for #1534 . To me the touch input is still broken and doing two touches to simulate one click is rather annoying (1x touch to drag the mouse pointer there and then touching the floating mouse click panel to trigger the click). My workaround is using both a VNC and a WebRTC connection at the same time... VNC for touch input and in the background WebRTC for all the other sweet and awesome features.

deekerman commented

2026-02-20 14:10:59 -05:00

Author

Owner

@mdevaev commented on GitHub (Dec 1, 2025):

I don't see an obvious way to distinguish a click from the desire for cursor positioning, so I can't suggest anything better. Any algorithm that I've looked at in various desktop clients leads to non-obvious results. Mouse and touch are fundamentally different input methods.

@mdevaev commented on GitHub (Dec 1, 2025): I don't see an obvious way to distinguish a click from the desire for cursor positioning, so I can't suggest anything better. Any algorithm that I've looked at in various desktop clients leads to non-obvious results. Mouse and touch are fundamentally different input methods.

deekerman commented

2026-02-20 14:10:59 -05:00

Author

Owner

@chuck-r commented on GitHub (Dec 16, 2025):

I know it's a bit of a niche use case, but I would like to be able to revert to the old-style input method on my tablet. In my case, my Samsung Tab S10E has a drawing tablet input, which is able to distinguish between pen hover (to move the mouse) and pen touch (for click). A simple mouse setting of "Drawing tablet mode" that uses the classic input method on a tablet with this type of input would be greatly appreciated.

Of course, right-click might still be an issue, but I really like the Android app Windows App (Microsoft's RDP client) way of doing things: touch and long hold for right-click with some kind of indicator for when the right-click is ready to activate on release. However, as mentioned in another post either here or in the original tablet issue I could probably just configure it so that the pen click is a right click, though I might have to reconfiure the pen every time I use PiKVM and then have to set it back when I'm done, which is a bit of a chore. An on-screen right-click indicator would be the best option, IMO. Microsoft's way of doing it is that when you touch and hold, a small, hollow circle fills up aroud the point of input and, when it completes a 360 degree rotation, a right click is triggered on release. This seems like a long-term goal. In the mean time, my workflow doesn't require right-click often so I can just pop open the mouse window when I abosolutely need a right click.

Edit: Apparently, I can not configure the pen click action.

@chuck-r commented on GitHub (Dec 16, 2025): I know it's a bit of a niche use case, but I would like to be able to revert to the old-style input method on my tablet. In my case, my Samsung Tab S10E has a drawing tablet input, which is able to distinguish between pen hover (to move the mouse) and pen touch (for click). A simple mouse setting of "Drawing tablet mode" that uses the classic input method on a tablet with this type of input would be greatly appreciated. Of course, right-click might still be an issue, but I really like the Android app Windows App (Microsoft's RDP client) way of doing things: touch and long hold for right-click with some kind of indicator for when the right-click is ready to activate on release. However, as mentioned in another post either here or in the original tablet issue I could probably just configure it so that the pen click is a right click, though I might have to reconfiure the pen every time I use PiKVM and then have to set it back when I'm done, which is a bit of a chore. An on-screen right-click indicator would be the best option, IMO. Microsoft's way of doing it is that when you touch and hold, a small, hollow circle fills up aroud the point of input and, when it completes a 360 degree rotation, a right click is triggered on release. This seems like a long-term goal. In the mean time, my workflow doesn't require right-click often so I can just pop open the mouse window when I abosolutely need a right click. Edit: Apparently, I can not configure the pen click action.

deekerman commented

2026-02-20 14:10:59 -05:00

Author

Owner

@mdevaev commented on GitHub (Feb 8, 2026):

@freituneir If you want to help the project, we are happy to accept PRs to the existing code. Feeding it into AI and creating a buggy copy of the code in which the entire internal structure is destroyed is a bad way to solve problems. It creates a system that will be impossible to maintain.

For many users, PiKVM is a means of emergency access, so it is highly desirable that the code be written by a human with a full understanding of what exactly he is doing. Otherwise, it can lead to completely unexpected bugs and frustrations.

@mdevaev commented on GitHub (Feb 8, 2026): @freituneir If you want to help the project, we are happy to accept PRs to the existing code. Feeding it into AI and creating a buggy copy of the code in which the entire internal structure is destroyed is a bad way to solve problems. It creates a system that will be impossible to maintain. For many users, PiKVM is a means of emergency access, so it is highly desirable that the code be written by a human with a full understanding of what exactly he is doing. Otherwise, it can lead to completely unexpected bugs and frustrations.

deekerman commented

2026-02-20 14:10:59 -05:00

Author

Owner

@freituneir commented on GitHub (Feb 8, 2026):

@freituneir If you want to help the project, we are happy to accept PRs to the existing code. Feeding it into AI and creating a buggy copy of the code in which the entire internal structure is destroyed is a bad way to solve problems. It creates a system that will be impossible to maintain.

For many users, PiKVM is a means of emergency access, so it is highly desirable that the code be written by a human with a full understanding of what exactly he is doing. Otherwise, it can lead to completely unexpected bugs and frustrations.

I'm happy for it to be a beta! I didn't make any changes to the internal structure, please let me know if I missed something! All I did was create a basic front end for the tablet mode, change the nginx conf to route to it, and change the landing page to have a link to the new tablet mode. It doesn't change anything about the normal KVM mode. I've been using it for some time and it works for me.

Sorry if I created more work, I figured it can help others while you create a more polished version. You can easily just scp the files onto the pi and change the mod and just go to /tablet

@freituneir commented on GitHub (Feb 8, 2026): > [@freituneir](https://github.com/freituneir) If you want to help the project, we are happy to accept PRs to the existing code. Feeding it into AI and creating a buggy copy of the code in which the entire internal structure is destroyed is a bad way to solve problems. It creates a system that will be impossible to maintain. > > For many users, PiKVM is a means of emergency access, so it is highly desirable that the code be written by a human with a full understanding of what exactly he is doing. Otherwise, it can lead to completely unexpected bugs and frustrations. I'm happy for it to be a beta! I didn't make any changes to the internal structure, please let me know if I missed something! All I did was create a basic front end for the tablet mode, change the nginx conf to route to it, and change the landing page to have a link to the new tablet mode. It doesn't change anything about the normal KVM mode. I've been using it for some time and it works for me. Sorry if I created more work, I figured it can help others while you create a more polished version. You can easily just scp the files onto the pi and change the mod and just go to /tablet

deekerman commented

2026-02-20 14:10:59 -05:00

Author

Owner

@mdevaev commented on GitHub (Feb 8, 2026):

@freituneir The frontend code, which used to be structured into modules and functions in a special way, has been redesigned by AI according to some of its own patterns. I mean: the call tree, the overall architecture of the frontend, even the coding style. It is no longer readable and understandable from my point of view.

I am grateful to you for your efforts and interest in the project, but I don't consider merging AI-generated code a viable direction for the project. I also don't want this issue to turn into a review: here we collect feedback on the existing interface and extract ideas from them. I think if someone is interested in your project, they will be able to use your repository and your issues.

If you want to contribute the code, the best way is to create PR that address specific issues to the current code. When doing that, please ensure that your code conforms to the existing stylistic and architecture choices and be prepared to explain and defend your code as if you personally have written it.

@mdevaev commented on GitHub (Feb 8, 2026): @freituneir The frontend code, which used to be structured into modules and functions in a special way, has been redesigned by AI according to some of its own patterns. I mean: the call tree, the overall architecture of the frontend, even the coding style. It is no longer readable and understandable from my point of view. I am grateful to you for your efforts and interest in the project, but I don't consider merging AI-generated code a viable direction for the project. I also don't want this issue to turn into a review: here we collect feedback on the existing interface and extract ideas from them. I think if someone is interested in your project, they will be able to use your repository and your issues. If you want to contribute the code, the best way is to create PR that address specific issues to the current code. When doing that, please ensure that your code conforms to the existing stylistic and architecture choices and be prepared to explain and defend your code as if you personally have written it.

deekerman commented

2026-02-20 14:10:59 -05:00

Author

Owner

@kusmi commented on GitHub (Feb 16, 2026):

I already like the KVM part on mobile/tablet. But I also sometimes use the terminal (and then SSHing into one of my servers) and there I currently miss a "floating keyboard" - perhaps the same as in KVM section which I could toggle (on the header-menu like on the KVM section).

Why?

Because when working on mobile using the terminal is quite cumbersome, because most tablets/phones don't have all "linux-keys" exposed, e.g. usually on iPad/iPhone you don't have an "ESC" key or a "TAB" key to quickly move around Linux.

So a floating keyboard (as in KVM section) would greatly improve the Terminal experience.

Additionally allowing to set the text-size in the terminal would also be great - but not strictly required, as most browsers allow to alter the text size already…

EDIT: I know, there is also a small Terminal window in the KVM section, but sadly if I also add the virtual keyboard, it will not send keystrokes to the terminal window, it only sends it to the WebRTC stream...

@kusmi commented on GitHub (Feb 16, 2026): I already like the KVM part on mobile/tablet. But I also sometimes use the terminal (and then SSHing into one of my servers) and there I currently miss a "floating keyboard" - perhaps the same as in KVM section which I could toggle (on the header-menu like on the KVM section). Why? Because when working on mobile using the terminal is quite cumbersome, because most tablets/phones don't have all "linux-keys" exposed, e.g. usually on iPad/iPhone you don't have an "ESC" key or a "TAB" key to quickly move around Linux. So a floating keyboard (as in KVM section) would greatly improve the Terminal experience. Additionally allowing to set the text-size in the terminal would also be great - but not strictly required, as most browsers allow to alter the text size already… EDIT: I know, there is also a small Terminal window in the KVM section, but sadly if I also add the virtual keyboard, it will not send keystrokes to the terminal window, it only sends it to the WebRTC stream...

deekerman commented

2026-02-20 14:10:59 -05:00

Author

Owner

@mdevaev commented on GitHub (Feb 18, 2026):

@kusmi the terminal is a third-party application and it's not bound with the uther UI, but I'll add your idea to the list.

@mdevaev commented on GitHub (Feb 18, 2026): @kusmi the terminal is a third-party application and it's not bound with the uther UI, but I'll add your idea to the list.

Rows
Columns

Mobile UI expirience #1090