Reverse-Engineered Userspace Driver for Asus ZenVision Lid OLED on Linux" • Hacker News Board

Re: Reverse-Engineered Userspace Driver for Asus ZenVision Lid OLED on Linux"

#11

Post by fragmede » Fri, Jun 05, 2026, 7:08 AM UTC

ghrl wrote: post #8

userbinator wrote: post #5

> 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 teste…

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.

Re: Reverse-Engineered Userspace Driver for Asus ZenVision Lid OLED on Linux"

#12

Post by yjftsjthsd-h » Fri, Jun 05, 2026, 7:52 AM UTC

fragmede wrote: post #11

ghrl wrote: post #8

Earlier quoted context omitted.

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 teste…

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)

Re: Reverse-Engineered Userspace Driver for Asus ZenVision Lid OLED on Linux"

#13

Post by stefan_ » Fri, Jun 05, 2026, 9:28 AM UTC

userbinator wrote: post #5

> 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.

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.

Re: Reverse-Engineered Userspace Driver for Asus ZenVision Lid OLED on Linux"

#14

Post by fragmede » Fri, Jun 05, 2026, 9:49 PM UTC

yjftsjthsd-h wrote: post #12

fragmede wrote: post #11

Earlier quoted context omitted.

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.