:: Re: [DNG] ..vdev input in X, was:..…
Pàgina inicial
Delete this message
Reply to this message
Autor: Arnt Karlsen
Data:  
A: dng
Assumpte: Re: [DNG] ..vdev input in X, was:..vdev box recovery ideas?
On Wed, 26 Apr 2017 17:51:15 +0200, Arnt wrote in message
<20170426175115.3d4873da@???>:

> On Wed, 26 Apr 2017 23:06:53 +1000, Ralph wrote in message
> <039e14e4-8f63-878a-5878-0e01bcb57b20@???>:
>
> >
> >
> > 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.
>
> ..we'll see about that, I have a ssh session handy. ;o)
>
> > 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.
>
> ..no mention of it down my /etc/initramfs-tools/ tree, and, it
> should have been in /usr/share/initramfs-tools/modules or in e.g.
> /usr/share/initramfs-tools/modules.d/modules.vdev ?
>
> ..aaand, my initrd.img-4.9.0-2-rt-amd64 played tough, so more torture
> ideas were needed, Osamu Aoki's getinitramfs script from Debian's
> #790095 squeezed out my trashed cpio archive, which contains evdev
> and vdev and a suspect "/conf/modules" with no mention of neither
> vdev nor evdev. But it works and I wanna know how and why. ;oD
>
> > 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.
>
> ..could, indeed. ;oD


..this is getting hilarious, I now have the mousepad working in
X, but not the keyboard joystick nor any keys or buttons.
Everything except the keyboard joystick and the top 3 buttons on
the mousepad, works in the console.
In my last goof boot, I found the hardware sound volume buttons
cleared the frame-buffer ;oD, so I carried on.

..and, I'm getting confused, I need your vdev-0.1.1, _and_ udev?
Which version, udev 220:3.2.2-2 amd64?

..udev whines about missing vdev's hwdb, should udev not have
its own hardware database? Or is that gone away into systemd?

..I have:
root@box:~# dpkg -l |grep -w udev |fmt -tuw 140 |cut -d" " -f 1-4
ii hdmi2usb-udev 0.0.0+git20161124-2 all
ii libeeze1:amd64 1.8.6-2.5+b2 amd64
ii libinput-bin 1.6.3-1 amd64
ii sg3-utils-udev 1.42-2 all
ii system-config-printer-udev 1.5.7-3+b1 amd64
iF udev 220:3.2.2-2 amd64
ii udev-discover 0.2.2-1.2 amd64
root@box:~# dpkg -l |grep -w vdev |fmt -tuw 140 |cut -d" " -f 1-4
ii vdev 20161228-jessie1 amd64
ii vdev-assistant 20161228-jessie1 all
ii vdev-dbgsym 0.1.1 amd64
root@box:~#

--
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.