Reverse-Engineered Userspace Driver for Asus ZenVision Lid OLED on Linux"
github.com59 points by berlianta 4 days ago
59 points by berlianta 4 days ago
If I'm reading correctly, this only uses generic support through the kernel (yay libusb), and actually implements all the interesting stuff in user space. If so, that's fantastic, because it means you don't need to patch the actual kernel, and that's really, really nice. I understand it's not always practical but I do wish as many drivers as were possible were at least initially supported like this, with kernel support later if we really wanted it.
For anyone else who was wondering what this looks like:
https://fdn.gsmarena.com/imgroot/news/22/12/asus-zenbook-14x...
https://fdn.gsmarena.com/imgroot/news/22/12/asus-zenbook-14x...
> CLAUDE.md
Reverse-engineered and vibe-coded? I've been seeing a lot more projects like this recently; it seems getting an AI to do a lot of the work for you has lowered the barrier to entry.
Yes, certainly. I've heard of people that let an agent run on one machine, point a USB Camera at the target and give the agent ssh access and something like imgsnap (cli webcam command) and then let it run autonomously. The agent can then try all sorts of things and also verify the results without asking the user. I think that's quite a good workflow, giving at least a basic feedback loop for work that can't be tested with just software.
For extra credit on top of the webcam, you can also add a Fingerbot, and a pi pico with either an Ethernet port or a second USB port, so the host machine can talk to the target device as if it was a keyboard, and then also hard power it off via holding the power button if the work wedges the machine.
Surely it would be simpler+cheaper to use a smart plug to kill power, at least for devices without a battery (or where removing it is easy)
Sometimes you need to do a specific sequence of power button presses to reach certain states. Eg a laptop may have a specific power button press to perform a warm reboot (instead of a cold boot which you'd get by cutting power), which preserves the previous crash in RAM. This helps you figure out where/why it crashed, instead of having to guess.
It's fantastic for reverse engineering like this. You still need to point it at the right resources of course (USB captures, a vendor driver binary, firmware dumps etc). And of course this mini OLED is somewhat of a throwaway feature to begin with.
And you need to be okay with the usual AI slop - like this sentence will make any kernel developer cringe:
"It is not a DRM display — you don't get a /dev/fb"
If you want it to exist in the Linux DRM subsystem, add a driver for it! It can be done easily for stupid USB framebuffer devices like this.
A cool thing would be to put a progress bar for something on the lid screen so you can see how long is left and open up the laptop when it is finished.
This might sound kinda campy… but I’d be totally down for something that makes it look like a toaster… haha
