Example of a dummy screen

[maitredede]

Hello,

I am trying to build an application to build a fake screen, but it seams that I am missing some things, since my display almost freeze.

I am using Debian 13 (trixie) that provides libevdi 1.14.8, on amd64 PC.

The principle of the program would be :

• init
• while no signal (sigint) do
  • dump on terminal display events (and get updated pixel values)
• cleanup

I did not find a working example that does not free my display, nor any doc of the lifecycle of an application using this library.

It looks like I hit a deadlock somewhere : a first call to evdi_handle_events allows to get the first display mode set, but the next poll (from evdi_get_event_ready) goes timeout.

When I receive a "mode change" event, I recreate and reregister the buffers, and ask for an update. But I never get a response back, and I can't use my computer.

I have a failsafe that stop my program after 1min (with a disconnect/close).

main.c

gcc main.c -o simulate_display -levdi -Wall
sudo timeout 120 ./simulate_display

[jakub-prussak-synaptics]

Hi, check out how it's done within pyevdi here, maybe it'll give you some clues.

[maitredede]

Hi @jakub-prussak-synaptics,

I tried to reproduce the behavior, but it looks like something is missing... I am writing a golang app that calls libevdi, and I also tried to bypass libevdi to talk directly to evdi/drm modules. I have the same behavior : events look stuck.

When my device is opened/connected, I have a loop that "polls" for events. The first events I have are "dpms on", "mode", "dpms on".

In the handler of the "mode" event, I unregister previous buffers (if any), then create and register buffers according to "mode" values. And I "request_update" for first buffer. Since it returns "false", I can't "grab_pixel".
Then no more events... The poll always return 0 (nothing available).

In the main loop, in case of the poll returns 1, it calls "handle_events", and after it calls "request_update" for same buffer (and if true, calls "grab_pixels").

In case of "grab_pixels", I switch buffers, then calls for an other update. But I have never got a buffer ready to call for grab.

[maitredede]

I have managed to write a CGO dummy screen, inspired by pyevdi and PR #423.

I loop until SIGTERM, draw grabbed pixels into a memory image, and on exit, save this image to disk as PNG.

Is it normal that the buffer is always fully redrawn (for a 1280x800, rect is always the full surface) ? How can I tell the right component to send only updated areas ? Is it relative to EDID content ?

Next steps, craft a custom EDID to target custom hardware, and remove CGO (use pure go).