This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Pavel Baturko pabftk at gmail.comHi list, Some time ago I proposed patch for supporting UCS2 USSD decoding, there was a discussion, but then unfortunately I have not received a response. Now I'm back to this subject and made small changes to decode UCS2 SMS by reusing code from USSD. But before sending new patch for SMS (and resend updated patch for USSD) I'd like to re-ask my last question in this thread: what to do with UTF-8 text after converting from UCS2? I sent patches with 3 variants: 1) Use setlocale to get available locales and set utf if possible and then print message. 2) Call external *nix command "locale" to check if utf is available and then print message. 3) Just print hex (with osmo_hexdump e.g.) I prefer #2, #1 may be also ok, #3 is bad because local (non-English) GSM providers often send service SMS/USSD messages in UCS2 and in that case reading hex instead of text is awful, also reading usual SMS from other MSs in hex uncomfortable too. Another problem is that using all of these methods makes impossible to read received SMS/USSD in VTY because AFAIU there is no way to check if console with VTY will be ok with UTF. Maybe it's possible to add flag to indicate that VTY can receive text in UTF? This flag may also cancel auto-detection of terminal's locale and shift responsibility to the user of this flag. But I'm not sure where this flag should be.. In my tests I just send decoded UTF text to VTY and all works fine. Another variant is inform user in VTY that message is printed in mobile log. So, what variant to choose when checking if terminal supports UTF? And how to interact with VTY in case of UTF strings? Thanks, Pavel