Add ibus unicode input support #3058
Conversation
Fixes a packet in the format send between xrdp and chansrv. UTF-16 surrogate pairs sent from the client are remapped to full unicode characters.
- xrdp is not now built with XRDP_IBUS to allow other input methods to be more easily supported. - chansrv is only aked to start an input method if the client supports it. - chansrv sends a status report back to xrdp when asked to start and input method. - ./configure without --enable-ibus now works.
libxrdp/xrdp_caps.c
Outdated
| // we can use it | ||
| if ((inputFlags & INPUT_FLAG_UNICODE) != 0) | ||
| { | ||
| self->client_info.unicode_input_support = UIS_SUPPORTED; |
There was a problem hiding this comment.
In my client, resizing the window repeatedly triggers the function xrdp_caps_process_input. The original UIS_ACTIVE state is reset to UIS_SUPPORTED, which results in subsequent failure to deliver.
There was a problem hiding this comment.
Thanks @poetic-edge - that's a good spot.
The way we're currently doing client resizes involves using the RDP Deactivation-Reactivation Sequence
Can you try this patch? I've run out of time today.
--- a/libxrdp/xrdp_caps.c
+++ b/libxrdp/xrdp_caps.c
@@ -424,16 +424,23 @@ xrdp_caps_process_input(struct xrdp_rdp *self, struct stream *s,
}
// We always advertise Unicode support, so if the client supports it too,
- // we can use it
- if ((inputFlags & INPUT_FLAG_UNICODE) != 0)
+ // we can use it.
+ //
+ // If Unicode support is already active, the CAPSTYPE_INPUT
+ // PDU has been received as part of a Deactivation-Reactivation sequence.
+ // In this case, ignore the flag.
+ if (self->client_info.unicode_input_support != UIS_ACTIVE)
{
- self->client_info.unicode_input_support = UIS_SUPPORTED;
- LOG(LOG_LEVEL_INFO, "Client supports Unicode input");
- }
- else
- {
- self->client_info.unicode_input_support = UIS_UNSUPPORTED;
- LOG(LOG_LEVEL_INFO, "Client does not support Unicode input");
+ if ((inputFlags & INPUT_FLAG_UNICODE) != 0)
+ {
+ self->client_info.unicode_input_support = UIS_SUPPORTED;
+ LOG(LOG_LEVEL_INFO, "Client supports Unicode input");
+ }
+ else
+ {
+ self->client_info.unicode_input_support = UIS_UNSUPPORTED;
+ LOG(LOG_LEVEL_INFO, "Client does not support Unicode input");
+ }
}
return 0;There was a problem hiding this comment.
Thank you. It is now functioning properly.
There was a problem hiding this comment.
Okay. I'll apply the patch.
|
@seflerZ - I've had a weekend break and have come back to discover a slightly fuller inbox than I was expecting. I'll got on to this as soon as I've cleared the backlog. Sorry. |
|
No problem. Take your time. @matt335672
|
xrdp/xrdp_mm.c
Outdated
| @@ -2447,6 +2559,9 @@ xrdp_mm_chan_process_msg(struct xrdp_mm *self, struct trans *trans, | |||
| case 18: | |||
| rv = xrdp_mm_trans_process_drdynvc_data(self, s); | |||
| break; | |||
| case 20: | |||
| rv = xrdp_mm_trans_process_unicode_ack(self, s); | |||
|
|
|||
|
Great to see people using this before we've merged it into devel. @seflerZ - thanks again for driving this. |
|
Hi, does anyone know how to make it work with password fields in a browser like a chrome? |
|
This feature takes advantage of iBus input. Have you tested whether iBus works with the password field? |
iBus not works for me with password fields in chrome, maybe because of the custom engine, I don't know, but I would like to find a way to fix it, is it working for you? |
|
@JulyIghor I'm using Microsoft Edge, but I think it's similar. I don't have problems about password input fields. |
Thanks for confirming, did you try to enter non latin characters? |
|
@JulyIghor Sorry, no. I think it is the field's word limitation which prevent you from entering non-latin passwords. Usually this is enforced by the website programmer or JS framework. |
I pushed latin characters via iBus and they are still ignored. Maybe it is some security feature forcing to use XIM for passwords. |
|
@seflerZ 8月 29 14:29:23 qingteng /usr/libexec/gdm-wayland-session[1523]: dbus-daemon[1523]: [session uid=132 pid=1523] Activating service name='org.freedesktop.portal.IBus' requested by ':1.35' (uid=132 pid=2191 c> ibus_engine_commit_text: assertion 'IBUS_IS_ENGINE (engine)' failed . --- always this error.
I looked at the process information on the system , both gnome-shell and systemctl started an ibus process at the same time. When I disable the ibus process started by systemctl, the effect is the same. I don't know what the problem is. I'm not familiar with ibus. Can you help me analyze it? |
|
@mengsongshan Open an issue if you encountered problems. The log tells everything goes, but the assersion fail unexpectly. You can describe the issue with more details. That is, can you input the ASCII text only or totally unavailable. |
|
Agreed - we need a separate issue to look into this. |
input the ASCII text no pro. I'm going to sort out the various scenarios, analyze the causes, and if I'm going to determine the various scenarios of the problem, I'm opening a issue. |
Close #1990 . This PR was made by me and @matt335672. It introduced serveral unicode input interfaces and has the ibus interface implemented (That means you should have ibus configured in the server side first).
The unicode input is a kind of method of sending unicode codes directly from the client to the server. With it, you can input any characters or glyphs (like Emoji 😁) even if they are not present in the keymap of the keyboard. It is typically used by mobile devices like Android\iOS phones, especially in Asia languages.
Another benifit of the unicode input is you can use your device's voice input to generate a bunch of texts quickly. Although we only have the ibus implemented now, it is easy to do for other input services like fcitx.
@matt335672 This is the latest rebased. Sorry I made merge before.