Hi  all ,

I had brought this issue up earlier a long  time ago,
see:=20

http://mail-index.netbsd.org/tech-userlevel/2004/11/25/0000.html=20

I had also attempted to fix this in userspace via kqueues ( that patch
is still available). The problem here is
that you will not be able to open any of the wskbd or ws*  devices  to
check for activity, due to the way wscons works. The hack I had posted
along with that mail works  partially, observing the ttyE* devices for
activity using kqueues results in inappropriate blanking when you have
sshed over to another system, and work on that. This activity is not
recognised by the ttyE* devices.

The problem with the atime etc not being updated is also in the above threa=
d,=20
see :
http://mail-index.netbsd.org/tech-userlevel/2004/11/25/0002.html=20
Basically,=20
mtime and atime are modified by
VOP_SETATTR().  As  the vfs is not involved  in the
code path that  required for a keystroke to get to the tty, the atime and
mtime for wskbd device is not modified.=20

This is where it ended the last time I looked at the code, IMHO, I
dont think getting the VFS involved is a good idea here. It seemed
perhaps the best way would be to modify wscons to have the screen
blanking in kernel.

On 5/6/05, Michael <macallan18@earthlink.net> wrote:
> Hello,
>=20
> > There's a PR for it (#17512), I don't think anybody has looked into it
> > any more. I got lost in the code trying to figure out the proper way
> > to update the times on the device as well. ;-)
> >=20
> > you can probably fix screenblank so it monitors the device for input
> > using kqueues or another interface if you want a userspace solution
> > rather than checking the times for the device which is what
> > screenblank does.
>=20
> I had a look at the code yesterday - can't see anything wrong with it on
> first glance, apparently it relies on device entries getting their
> modification time set whenever something happens so it's no surprise it
> didn't work for me - / is mounted with nodevmtime and noatime to let the
> disk spin down. Maybe I should put /dev into a RAM-disk...
>=20
> have fun
> Michael
>=20
>