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
> 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
Alan Cox, le Tue 21 Jul 2009 00:51:08 +0100, a ?crit :
> 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
Sounds like a good plan indeed.
Samuel