Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

implement wait for update ioctl #44

Closed
raisjn opened this issue Jan 31, 2021 · 3 comments
Closed

implement wait for update ioctl #44

raisjn opened this issue Jan 31, 2021 · 3 comments

Comments

@raisjn
Copy link
Collaborator

raisjn commented Jan 31, 2021

in mxcfb on rM1, using ioctl there is ability to do:

send_upate { update_marker: X };
wait_for_update { update_marker: X};

in rm2fb, there is no longer the "wait for update" ability due to two things:

  1. there's only single way communication from client -> server
  2. the framebuffer API has a command, "waitForLastUpdate()" but it does not support supplying a marker ID (i think). translating "send_update; wait_for_update ID" into "send_update; waitForLastUpdate()" requires knowing when to call waitForLastUpate() after drawing an update, but the wait_for_update can come at any arbitrary time and we process the incoming events in order.

this task is to give the ability for rM2 apps to wait for a previous draw to finish.

@raisjn
Copy link
Collaborator Author

raisjn commented Feb 1, 2021

some possible solutions:

  • hardcode some amount like 200ms (see implement wait for update ioctl #44)
  • add a function that guesses the draw time based on region size and waveform
  • implement event system from server that client can subscribe to

@raisjn
Copy link
Collaborator Author

raisjn commented Feb 5, 2021

another solution proposed (by bokluk) is to use semaphores and would work something like:

when WAIT ioctl is issued on the client:

  • the client places a special messages into the IPC queue. the message contains the ID of the semaphore to signal.
  • then the client waits on that semaphore (with a timeout just in case).
  • when the server gets to processing this message, it opens the indicated semaphore and signals that its ready

@raisjn
Copy link
Collaborator Author

raisjn commented Feb 8, 2021

first attempt in #45. this solves some weird behavior i was seeing in an app previously and i expect it should work in other places too

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant