inotify on /dev/vcsa?

[Samuel Thibault]

Hello,

Powersaving is everywhere, including accessibility. User-level daemons
use /dev/vcsa to know what text is displayed on the screen. Problem
is: there is no way to _wait_ for an update to happen, so these daemons
actually poll every e.g. 40ms so as to be reactive enough for smooth
user experience. That means waking up 25 times per second, which is not
so greenish while the computer could be completely idle else.

An ioctl could be devised to wait for updates, but I was wondering
if there could be a way to just use inotify for that. However,
drivers/char/vc_screen.c would have to collect the list of opened files
in order to notify all of them (processes may even have opened another
node with same devno as /dev/vcsa), which is not really pretty, and
actually maybe some other device drivers would want to achieve the same
kind of thing, so I was wondering whether that could fit into another
place like the generic device infrastructure?

Samuel

[Alan Cox]

Post by Samuel Thibault
An ioctl could be devised to wait for updates, but I was wondering
if there could be a way to just use inotify for that. However,
drivers/char/vc_screen.c would have to collect the list of opened files
in order to notify all of them (processes may even have opened another
node with same devno as /dev/vcsa), which is not really pretty, and
actually maybe some other device drivers would want to achieve the same
kind of thing, so I was wondering whether that could fit into another
place like the generic device infrastructure?

I would have thought poll() would have been cleaner. Or perhaps extending
the VT event interface I added to the vt drivers in the current patches
pending for 2.6.32 - poll support would probably be a bit lighter as
you'd just need to do something like

event_count++;
wake_up(&vcsa_event_wait);

and check for a count change
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Samuel Thibault]

I would have thought poll() would have been cleaner. Or perhaps exten=

ding

the VT event interface I added to the vt drivers in the current patch=

es

pending for 2.6.32 - poll support would probably be a bit lighter as
you'd just need to do something like
=20
event_count++;
wake_up(&vcsa_event_wait);
=20
and check for a count change

Sounds like a good plan indeed.

Samuel
--
To unsubscribe from this list: send the line "unsubscribe linux-console=
" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html