ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
Droop has quit []
Droop has joined #asahi-dev
ah- has joined #asahi-dev
ah-_ has quit [Remote host closed the connection]
ah- has quit [Ping timeout: 480 seconds]
ah- has joined #asahi-dev
darkapex2 has joined #asahi-dev
darkapex1 has quit [Ping timeout: 480 seconds]
kesslerd has quit [Quit: Konversation terminated!]
<marcan>
yeah okay, we need the kblang thing then. sigh.
<marcan>
robher: got some time to talk about keyboard layouts in device trees? there are two levels to the mess:
<marcan>
- specifying/overriding the HID country code (which is a standard device property for real HID devices). we could just go apple,country-code, but this feels like this should probably be a standard prop?
<marcan>
however, HID country codes are useless for specifying actual keyboard layouts (they get way more complex than that). Apple only uses them to select among the 3 physical keyboard types (key arrangements), not the layout printed on the keycaps.
<marcan>
- so then we need something to specify the *actual* layout, in detail, in the device tree
<marcan>
input: our bootloader knows the layout from system firmware, as a proprietary enum
<marcan>
output: userspace eventually needs to know what xkb layout to use (and the equivalent best-fit console keymap, though console keymaps are pretty hit and miss anyway)
<marcan>
how should this be expressed in the device tree? if we go with a country code type thing, that's lossy and userspace then still needs at least per-vendor tables (and Apple sometimes has more than one layout for a given country and not-technically-country-specific layouts, which is an issue).
<marcan>
if we go with outright putting xkb type/model/options into the DT, that would nicely solve the problem but creates an interesting spec dependency with the xkb stuff (and that isn't as strictly managed as DT bindings are re backwards compat etc)
<marcan>
alternatively we could just punt on standardizing any of this and keep doing what we do now, which is just shove the Apple-specific enum code somewhere and have userspace handle mapping that, but that's... maybe not ideal.
<marcan>
right now we have that in /chosen which is probably also suboptimal (I imagine it should go in the HID device node)
<marcan>
jannau: oh lol, kblang-calibration is just 2 bytes and then a CRC32 of those 2 bytes.
<marcan>
okay, that eliminates a lot of mystery.
<marcan>
and the first byte is the version
<marcan>
so this is really just the language code
<marcan>
no other info
<marcan>
okay, that's one set of "what if we need more data" questions answered
<marcan>
jannau: can you run experiments/mtp.py and paste the output? I think I might have found the real keyboard type.
<marcan>
nevermind, macOS just has a table of the kblang -> everything else
<marcan>
so we get to do the same
<marcan>
it's actually just in AppleTopCase.kext/Contents/PlugIns/AppleTopCaseDriverV2.kext/Contents/Info.plist
<marcan>
and there's more than one table, of course
<dottedmag>
mps: IANAL, better check with the real one. However https://github.com/ipmitool/ipmitool was archived by GH today, due to a having developer from that company.
<povik>
huh
<mps>
ipmitool is archived two days ago
<mps>
but this is company decision, not an open source entity
<povik>
is there a statement from github about this?
<povik>
could the developers have archived it?
<mps>
dottedmag: though I agree, also IANAL
<mps>
github is known of doing such actions quietly for some time
<mps>
povik: ipmitool is archived already somewhere, I didn't followed where because I don't use it for two years now
<mps>
happily I advised alpine to install gitlab instead of moving to github from patchwork
<mps>
(hm, happily or luckily, not sure which is proper term)
<sven>
that also all sounds off topic
<mps>
right
tobhe has joined #asahi-dev
tobhe_ has quit [Ping timeout: 480 seconds]
veeyee has joined #asahi-dev
<povik>
mps: no, i meant could it have been the developers who marked the github repo as archived