Closed digitaltrails closed 7 months ago
Passing a binary array winds up inefficiently represented in python as a list of bytes - so I don't think passing a byte array (ay) is the way to go.
The interface seems fast enough when passing hex, but we could go to base64 if it was a serious concern.
len=256
00FFFFFFFFFFFF0022F069280101010108140104A53623782EFC81A4554D9D25125054210800814081809500A940B300D1C001010101283C80A070B023403020360022602100001A000000FD003B3D185011000A202020202020000000FC004850205A523234770A20202020000000FF00434E5430303831314A360A2020003D
len=172
AP///////wAebQd3e1EBAAQdAQS1PCJ4nj4xrlBHrCcMUFQhCABxQIGAgcCpwNHAgQABAQEBTdAAoPBwPoAwIGUMWFQhAAAaKGgAoPBwPoAIkGUMWFQhAAAaAAAA/QA4PR6HOAAKICAgICAgAAAA/ABMRyBIRFIgNEsKICAgAZ4=
len=160
0RR90|Ns909&HDAdr<)Z1RVhcwLBtto<1?IP)DpM3{X@d2mo<Ffq;R)sld^|fdByk0Rc_W0HE-2K7cSFWeiwUApigxC};qn@NhnW2#{qASX3bZ02%-Q0Q~?sJsyWR016-=ARr(h0002|08B?9NJLT~G)oE~ARqyr
It might be possible to use dasbus type hints to allow edid to returned as a binary instead of as a list of bytes. But I need to find an example of how to do that.
Experimentally changed the EDID encoding to base64. This seems OK, it's certainly shorter. I made vdu_controls
neutral in respect to the EDID encoding, when interacting with dbus, vdu_controls
now just treats the the EDID as some kind of string without regard to what it contains.
EDID encoding to base64 is the winner
Currently the EDID in hex is passed as the VDU unique ID (or optionally the display number). The did in hex is quite large compared to the other data, it doesn't appear to appreciably slow down the interface, but I wonder if a shorter/smaller option might be better, possibilities:
KDE has switched to using the edid, so I suspect one form or another of the edid is the way to go.