Skip to content

Conversation

@mfudpi
Copy link

@mfudpi mfudpi commented May 10, 2023

Since [1], writing to the fbtft framebuffer and immediately closing the file descriptor is likely to have no effect. This is because the framebuffer deferred IO framework is now careful to cancel pending updates.

To retain the old behaviour, add an fb_release method that flushes the updates instead.

See: #5399

[1] 3efc61d ("fbdev: Fix invalid page access after closing #deferred I/O devices")

Since [1], writing to the fbtft framebuffer and immediately closing
the file descriptor is likely to have no effect. This is because the
framebuffer deferred IO framework is now careful to cancel pending
updates.

To retain the old behaviour, add an fb_release method that flushes the
updates instead.

[1] 3efc61d ("fbdev: Fix invalid page access after closing deferred I/O devices")
@pelwell
Copy link
Contributor

pelwell commented May 10, 2023

You're submitting a minor tweak on my PR (#5399) but without mentioning the fact in the PR? I guess the See: counts.

If you'd read around a bit more you'd find that I submitted an alternative workaround (#5413) that should work for all drivers using fb_deferred_io without causing slow-down for user-space code that rapidly opens and closes the device.

@mfudpi
Copy link
Author

mfudpi commented May 11, 2023

Thanks for pointing me that direction, must have missed your alternative workaround.

Unfortunately #5413 does not work in my case.

Writing to the framebuffer and closing the file descriptor immediately does not have any effect.
Running cat /dev/urandom > /dev/fb0 afterwards does not update the display.

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

Successfully merging this pull request may close these issues.

2 participants