Hi Yang, > >Please drop this patch for now, the problem is that all AT modems do not > >actually report USSD data as a PDU, instead they actually decode this into > > the current character set of the modem (as set by +CSCS.) The spec > > really screwed up on this one. > > > >This is one of the weirder parts of the spec, I don't think USSDs that are > > not GSM 7 bit are even possible. At least not on the AT modems I've > > encountered. > > When it's GSM 7-bit, is it needed to call unpack_7bit() before calling > convert_gsm_to_utf8()? The isimodem does so. Also the status doesn't have
Again, the AT modems do not pass in a raw PDU here unlike isi modems. They just give you the string in whatever the character set is set with +CSCS. If it happens to be UTF8, it will be UTF8. If it happens to be GSM, it'll be GSM. The current driver just assumes GSM, however we really need to know the character set. Generally this works out because the characters are ASCII, but the current driver does not work in all situations. > an initial value, so in some path of code status would have an uncertain > value, which may cause problem when calling ofono_ussd_notify(). Maybe the I don't see any issue, from what I can tell status is always set appropriately before calling ussd_notify. Can you be more specific about your concern here? Regards, -Denis _______________________________________________ ofono mailing list [email protected] http://lists.ofono.org/listinfo/ofono
