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-a4582ab9d36f@???>:
>
>>
>>
>> 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-f9d7156bbaa7@???>:
>>>
>>>>
>>>>
>>>> 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.