<sven>
jannau: thanks! looks like usb4 indeed sets different bits than tbt altmode in that data status register
user982492 has quit [Ping timeout: 480 seconds]
<Dcow>
different from thunderbolt3?
<sven>
i think so. technically thunderbolt 3 is an alternate mode while usb 4 isn't (lol, usb)
<chadmed>
of course its different, the usb-if's primary objective is to cause sven grief. maintaining usb is merely a consequence of that
<Dcow>
yeah, sometimes I read the logs and just want to send sven flowers or a cake to cheer him up
<ChaosPrincess>
So, kind of a RFC: how to represent the touchbar for consumption by linux kernel. I have reversed most of the digitizer protocol, but idk how to hook it up properly.
<chadmed>
if its HID/HID-like i imagine you could draw some inspiration from the existing HID touchscreen drivers
<ChaosPrincess>
the problem is that it is not _quite_ a touchscreen
<ChaosPrincess>
i guess i can try doing it as a regular touchscreen, but its likely to confuse userland
<chadmed>
what special handling does it need specifically?
<ChaosPrincess>
i do not want users to be able to drag a normal window there :P
<chadmed>
ah of course :P
<chadmed>
are there any drivers for those cringe little screens they put on PC AIOs et al these days?
<ChaosPrincess>
those screens tend to be connected to a microcontroller that actually drivers the screen, and communications are done over usb.
<chadmed>
is there nothing like that in front of the touchbar?
<ChaosPrincess>
and while i haven't looked too close at the screen part, it looks like there is just a framebuffer there
<ChaosPrincess>
not on m1 touchbar, t2 had it, but you could also send framebuffers there
<chadmed>
sounds like something that would benefit from a bespoke userspace lib that does any special stuff with ioctls
<chadmed>
if its just a dumb framebuffer with a digitiser on top of it that we cant represent as a "normal" touchscreen
chadmed_ has quit [Remote host closed the connection]
<Dcow>
it's like embedded stream deck
<ChaosPrincess>
yea, something like that
MajorBiscuit has joined #asahi-dev
c10l has quit [Read error: Connection reset by peer]
c10l has joined #asahi-dev
<povik>
sounds to me like it should be a regular touchscreen kernel-wise
<povik>
no point in not using the right interface that's already there because you want to make it less compatible and enforce use-case
dsharshakov has joined #asahi-dev
<dsharshakov>
ChaosPrincess: hello! I wanted to reach out to either you or T2 people about touchbar userspace
<Dcow>
just imagine KDE panel there ;)
<dsharshakov>
I think of writing a Rust-based touchbar service `auxdisplayd` for such cases as touchbar, ASUS ScreenPad or custom touchscreens makers want to attach
* Dcow
even don't have any touchbar devices anymore
<_jannau_>
ChaosPrincess: iirc drm has a flag for non-desktop display devices
<ChaosPrincess>
_jannau_: how does that work?
<dsharshakov>
It'd have a D-Bus (or socket) API for apps to register widgets with, as well as own widgets such as Fx (+esc) buttons or sth like that
<dsharshakov>
Likely we can avoid drm, since that's unlikely to fit well. T2 touchbar is a framebuffer, not a proper display controller with swaps etc
<dsharshakov>
There's been a MIT-licensed BootCamp driver for TouchBar by someone, that just pushes pixels over usb
<ChaosPrincess>
yea, i looked at that, but i think it does swaps, no?
<j`ey>
"@non_desktop: Non desktop display (HMD)." (in include/drm/drm_connector.h, not sure what HDM is)
<chadmed>
head-mounted display?
MajorBiscuit has quit [Ping timeout: 480 seconds]
<j`ey>
chadmed: ok like vr stuff
<dsharshakov>
a drm driver would be difficult to prevent from being grabbed by the compositor (likely we'll have to either place our quasi-window there or ask for a DRM lease)
<dsharshakov>
"ok like vr stuff" <-- yes, for that
<chadmed>
yeah vr, but probably also used for significantly more lethal devices id say
<ChaosPrincess>
fighter pilot helmet? :P
<chadmed>
thats what i was thinking of yeah heh
<dsharshakov>
Probably a FB driver should be sufficient to render the touchbar at its 60 Hz with plain pixel copies. Maybe it'd be great to co-ordinate with T2 devs to propose a common device api to expose touchbar display with
<chadmed>
fwiw all those elgato stream deck things share some python lib for actually doing things with them
<ChaosPrincess>
is there even a t2 touchbar driver that exposes full features and not just f-keys for linux? i only know of a winders one
<dsharshakov>
I wanted to ask them whether someone can port that bootcamp driver to Linux to later try with my `auxdisplayd` approach
<ChaosPrincess>
chadmed: yea, but they are behind a usb attached controller that actually draws the screen, while m1 seems to have it in software
<dsharshakov>
Yes, but existence of one means people discovered how to talk to bridgeOS to customize the touch bar. Maybe lack of Linux driver is just bc nobody cares
<sven>
the hw interface is likely the same, it's just that apple wrote their own driver running on the T2 and somehow proxies that over a custom usb protocol
<ChaosPrincess>
pmuch that
<dsharshakov>
and t2linux likely have less work to do and somebody might devote their time to writing a Linux driver + discussing the concept
<_jannau_>
ah, non_desktop/HMD isn't that useful then. So the hope is then that compositors prefer screens with height > 128 pixels or what ever resolution the touchbar has
<dsharshakov>
I wouldn't trust in compositors that much
<sven>
let's please not bypass some kernel framework just because compositors are possibly broken
<dsharshakov>
Maybe a new flag? Non_desktop | non_vr = don't touch unless asked to?
<ChaosPrincess>
yea, i want to just hook it up in a sane way, just maybe hide it from the compositor
<sven>
ChaosPrincess: yeah, that sounds good
<dsharshakov>
they mustn't use non_desktop screens unless asked by a VR client, and the NON_VR flag will tell VR clients to avoid the bar as well
<dsharshakov>
However, should touchbar support be in or stay away from compositors? I'm mostly for the latter approach for better cross-desktop support and easier app integration
<dsharshakov>
However, someone might have different ideas and then compositor must use the touchbar, but just know about it and use wisely
<chadmed>
imho i think its a cool exercise in RE and all that, but theres very little chance anyone is going to put in the dev time to support it in desktop apps. even apple seem to have abandoned it
<chadmed>
and if its an EOL feature on the machines then theres even less incentive for people to support it
<dsharshakov>
Maybe the question should be postponed to when there's understanding of the display controller such as a m1n1 experiment, so that we see the properties better and know whether it's DRM or not
<povik>
right, better not make grandiose plans with it and instead head for some minimal usable integration
<_jannau_>
please don't start worrying about this before there is at least a PoC mipi drm/kms driver
<ChaosPrincess>
if there is support for f-keys and maybe 1 alternative layer with the fn+f-keys, i'd be happy
<sven>
_jannau_: +1
<dsharshakov>
_jannau_: +1, first we need an understanding of the device to know how to hook it up in kernel
<_jannau_>
the hardware ought to use standard interfaces. if user space can not deal with that we have to and can fix user space
<dsharshakov>
The userspace part could be discussed in T2 chats, since apparently there's a knowledge on how to get the display working on those machines
<povik>
huh? "how to get the display working" and "the userspace part" sound unrelated :D
<dsharshakov>
Some more integration than virtual keys is possible: volume + brightness controls (sliders) and global menu can be done relatively easily
<dsharshakov>
povik: I mean if they're interested they know how to do a driver and then try out userspace stuff
<dsharshakov>
(and the USB driver could easily live in userspace as well)
<dsharshakov>
maybe hwdb or libinput quirks can be used to disable the touchscreen input from being mapped, so touch part can be exposed as a touchscreen
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
leitao has quit []
user982492 has quit [Ping timeout: 480 seconds]
leitao has joined #asahi-dev
leitao has quit []
minecrell has quit [Remote host closed the connection]
minecrell has joined #asahi-dev
c10l has quit [Ping timeout: 480 seconds]
c10l has joined #asahi-dev
tobhe_ has joined #asahi-dev
tobhe has quit [Ping timeout: 480 seconds]
leitao has joined #asahi-dev
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nicolas17 has joined #asahi-dev
leitao has joined #asahi-dev
leitao has quit []
MajorBiscuit has quit [Ping timeout: 480 seconds]
leitao has joined #asahi-dev
leitao has quit []
leitao has joined #asahi-dev
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
garuru11 has joined #asahi-dev
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
beeblebrox has joined #asahi-dev
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
amarioguy2 has joined #asahi-dev
amarioguy2 has quit [Remote host closed the connection]
gladiac has joined #asahi-dev
gladiac has quit [Quit: k thx bye]
kode54 has quit [Quit: Ping timeout (120 seconds)]
kode54 has joined #asahi-dev
jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi-dev
leitao has quit [Remote host closed the connection]
leitao has joined #asahi-dev
tenkuu has joined #asahi-dev
<marcan>
sven: you've got mail :)
<marcan>
dsharshakov: it's DRM, it has to be DRM (the legacy framebuffer stuff is deprecated)
<marcan>
using those flags to keep it out of compositor's reach sounds like a plan (or maybe new flags or something, maybe discuss with #dri-devel?)
<marcan>
but I expect we'll have a daemon doing uinput to emulate F keys and that's that for a while
<marcan>
and yes we'll need a libinput quirk similarly, to keep it from being interpreted as a regular touchscreen
<sven>
ok, will take a look later
dsharshakov has joined #asahi-dev
<dsharshakov>
marcan: yes, uinput + many decent things daemon is what we want likely. I wanted to discuss some of its working principles. It could be done with Rust and egui (just see it, appears to be a nice toolkit which can be shaped into a touchsceen-first UI for constrained space)
<dsharshakov>
However, it's necessary to know how should it access the device and will it be root or not. Likely needs to be either root or a system daemon getting uinput access permission
<dsharshakov>
And then things go much complex since it will also need to keep track of user logins, seat and VT management etc...
dsharshakov has quit [Quit: Page closed]
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
gladiac has joined #asahi-dev
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
___nick___ has joined #asahi-dev
___nick___ has quit []
gladiac has quit [Quit: k thx bye]
___nick___ has joined #asahi-dev
garuru11 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
garuru11 has joined #asahi-dev
___nick___ has quit [Ping timeout: 480 seconds]
nicolas17 has quit [Quit: Konversation terminated!]
garuru11 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
garuru11 has joined #asahi-dev
garuru11 has quit [Read error: Connection reset by peer]