Arnt Karlsen wrote on 26/04/17 22:01:
On Wed, 26 Apr 2017 18:52:58 +1000, Ralph wrote in message
<d67b7404-6f6b-0cff-bca3-a4582ab9d...@gmail.com>:
Arnt Karlsen wrote on 26/04/17 17:26:
On Wed, 26 Apr 2017 12:08:48 +1000, Ralph wrote in message
<2fab2208-e0dc-27f5-dd3d-f9d7156bb...@gmail.com>:
Arnt Karlsen wrote on 26/04/17 11:18:
[cut]
I believe keyboard and mouse needs the "evdev" module to be loaded
before something; certainly before starting X.
..aye: root@box:~# lsmod |grep evdev
evdev 24576 26
root@box:~# lsmod |grep vdev |grep -v evdev
root@box:~# lsmod |grep dev |grep -v evdev
input_polldev 16384 1 lis3lv02d
ipmi_devintf 20480 0
ipmi_msghandler 49152 3
ipmi_devintf,ipmi_poweroff,ipmi_watchdog ppdev
20480 0 parport 49152 3 lp,parport_pc,ppdev
videodev 180224 3
uvcvideo,videobuf2_core,videobuf2_v4l2 media
40960 2 uvcvideo,videodev joydev 20480 0
root@box:~#
Yeah, you would do "lsmod | grep -w evdev" only, and apparently it's
loaded, so probably not the issue. You can check inside initrd image
that "evdev" is mentioned in the "conf/modules" file to ensure/verify
that it happens early enough.
Note that "vdev" itself is not a module, but is present in a number
of pre-pivot init scripts, the vdevd daemon, and its configuration
files. The vdevd daemon is run twice: once pre-pivot, then that one
is killed and another is started via the /etc/init.d/vdev script.
[cut]
Perhaps /var/log/Xorg.0.log tells something.
..3 of them here: https://pastebin.com/qsNGW8G0
And I have this vague
memory of being in that same situation, but I can't remember the
resolution.
Ralph.
..aye, had I remembered what I did last time around... ;oD
Right. My guess from those is in fact that evdev is not loaded early
enough, because your logs don't mention it at all. I think the story is
that evdev needs to be loaded to handle "device events" from vdev when
it populates /dev/input, which it does at its pre-pivot run. Loading it
later (perhaps automatically by the start of X) is of little help,
because there are no new device events.
You can test that theory manually by the following sequence:
# kill $(cat /run/vdev/vdevd.pif)
# rm -r /dev/input && /etc/init.d/vdev start
NOTE THOUGH that "rm -r /dev/input" may well kill your console input
instead, and you might need to power-toggle to recover.
BUT, it's also believable (to me) that the restart of vdev after having
removed all /dev/input/* entries will cause it to re-populate
/dev/input, and now (since evdev has been loaded) it should also tickle
evdev usefully. By that idea it should recover any lost console input as
well as setting up evdev for the X input.
In either case, you need to make sure that evdev is indeed in the
"conf/modules" list in the initrd image, which is how it's loaded. If
it's not already in there, your initrd is likely to be a remnant from
your Gnuinos' vdev experiments, or at least, not an initrd including the
Devuan's vdev scripting. In that case, a --reinstall could do wonders.
Ralph.
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
