New (ascii from jessie) install, mouse not working

ghaverla · 2017-07-02 14:14:58

I have an older machine (Dell Optiplex 740 SFF) which had Debian/Jessie and Windows XP installed on a small hard disk. I replaced the hard disk with a bigger SSD, and partitioned it in such a way as to allow for 2 Devuan installations. A set of partitions (mostly btrfs, some ext[24]) and as a single ext4 partition (last one). There is some unallocated space beyond the last partition. I installed Devuan/Jessie to the single ext4 partition using the netinst CD, and then because I forgot a detail, did the install again with the Devuan DVD. I upgraded to Ascii, so as to get a 4.x kernel and rebooted. With a 4.x kernel working, I then put btrfs, ext4 or ext2 filesystems on the other partitions as planned, and proceeded to copy parts of the single partition installation over to the multiple partition one. There was some hickup about getting grub set up on the new set of partitions.

Along the way on booting, I seen the gui Devuan login screen, but never used it. I just changed to a text console and logged in as root.

With things starting to work, I thought I would do a gui login. There was no mouse (cursor). Unplugging the USB mouse and plugging it back in, same result. No mouse.

I see that inputs to X are now handled with libinput, which I have never worked with before (part of Wayland?). I didn't know if libinput was the problem, but I tried to see if falling back to evdev would fix things. So, I added a mouse snippet to /etc/X11/x.conf.d to allow for evdev on mice (pointers). And I can see in the Xorg.conf.0 log file, that it is correctly going over to evdev. And then the next 2 lines show that udev doesn't know what to do, and so it will ignore the mouse.

It doesn't matter to me (too much) whether I go back to libinput, or continue with evdev. But how does one get the mouse working? Or rather, how does one troubleshoot this?

Thanks.

PeteGozz · 2017-07-02 16:05:31

I am running Linux 4.11.6-lenny i686 GNU/Linux
I don't think the mouse issue is _directly_ kernel version related though I still use evdev
(and my usb or ps2 mouse is working)

The whole mouse thing is (these days) a pain again...
Its the only thing that will reliably 100% fail with eudev vdev rather than udev here at least.

Maybe something here will help:
make sure you have an entry that achieves something like this in /etc/fstab.

# this "udev" gets mounted again (?) by /etc/init.d/udev
# and could probably not be here. the "udev" is really just sugar
udev /dev devtmpfs rw,nosuid,relatime,mode=755 0 0

The kernel exports userspace events to that tree.
udev and are supposed to just hand this stuff out when it alters.

try restarting udev
replug usb mouse and

$ sudo service udev restart
(which my inits do on boot but maybe i forced that at some point)
$ dmesg may say something useful

$ sudo apt-get install gpm
General purpose mouse .
That should work on the console at least.
(and tests usb etc)

################################
OH *ding* this made a huge difference earlier ...
ensure evdev is loaded before X starts
add evdev /etc/modules (so it gets forced in at boot)
or an insmod evdev or similar when slim (or your display manager) starts
################################

modprobe evdev
lsmod
insmod

and the always useful..

[root@lenny]: /home/pete$ modinfo evdev
filename: /lib/modules/4.11.6-lenny/kernel/drivers/input/evdev.ko
license: GPL
description: Input driver event char devices
author: Vojtech Pavlik <vojtech@ucw.cz>
alias: input:b*v*p*e*-e*k*r*a*m*l*s*f*w*
depends:
intree: Y
vermagic: 4.11.6-lenny SMP mod_unload modversions CORE2

? add evdev to etc/modules ?
Though I don't have that and my mouse works fine with udev loaded.
The system still works fine.
(I use it for a nic card or two)

If your kernel has it you can try loading module evbug
It will flood dmesg though.
(maybe from console)

So last resort.

sorry to shotgun stuff in mess like that but I have to sleep

ghaverla · 2017-07-02 22:52:42

To start with, there were quite a few things being mounted, that were never in fstab. Udev is one of them.

Unplugging and replugging in the USB mouse, sees changes to /var/log/(messages,Xorg.log.0). The Xorg file says mouse still being ignored (and I still have no mouse on GUI login screen). Restarting the udev service, sees messages in Xorg.log.0, but nowhere else. As far as input devices goes, the Xorg.log.0 shows stuff about the libinput devices: power button, USB keyboard. Dmesg shows a USB event, There is a input line for the mouse with a pci address, and then a hid line about a USB mouse.

I see that the installation has installed libgpm2 (a long time ago). Installing gpm goes fine. No change to Xorg.log.0, but messages has a change indicating that gpm daemon started succesfully.

Unplugging and replugging mouse has similar results to earlier, and still no mouse/cursor on the GUI login screen.

Added evdev to modprobe file. Evdev is loaded (was before too, but I didn't know when). Gpm works on the console. Modinfo evdev shows same thing you have (I was going to say author changed to Admiral Pavel Checkov, United Federation of Planets).

Module evbug does not exist here.

I don't mind the shotgun, I need to get practiced up. Next thing is to get fglrx on this machine. And as near as I can tell, I have to import Debian packages for that. I hope you got a good sleep.

Fortelling other threads to come. This machine has a HD5450 card, so not very much of a GPU. It needs Catalyst. Another machine has a HD6450 card, so a bit more oomph, it too will need Catalyst (and probably comes last). A third machine has an A10 APU and a R7-250 card, it needs Crimson (Catalyst for multiple GPU), which I have never got running. And fourth machine will have a RX-460. And if that isn't enough numbercrunching ability, I plan to set up a machine with a Ryzen 1600x and a RX560 (or two of them). I have some weather/climate modeling to do.

PeteGozz · 2017-07-03 01:06:17

:::: Its less likely this is a permission thing for $USER (you) under X ::::
(Though maybe its one of those console-kit pieces of helpful rolling breakage)
The include snippet _may_ help ..

However there may be something here and you can test (see: next rambling post)

there were quite a few things being mounted, that were never in fstab. Udev is one of them.

I was checking that input was working and devtmpfs was _ensured_ .

Which should mean "input" is working under /dev/ etc.
(not relying on say X to start something or some other helpful complicator.)

For clarity
I should have said:
What does mount say about option mode=nnn and devtmpfs or maybe
(little old school )

cat /proc/mounts | grep devtmpfs
ls -lah /dev/input/mice

mode 755 for the first
notice group access for the ls -lah
But given you have a /dev tree the above is a wander off to nowhere as :

I'm not in the group input ... mouse works with X
Or plugdev ... ditto

So perhaps another mechanism is at work.
You can check "id" and add yourself to plugdev and netdev

FWIW

## /etc/X11/xorg.conf.d/30-mouse.conf

Section "InputDevice"
        identifier      "Mouse0"
        driver          "mouse"
        option          "AutoServerLayout"      "on"

        # /dev/input/mice will provide support for hotpluging mouse.
        # >>>Without needs to restart X server.<<<< 
        option  "device"        "/dev/input/mice"
        #option "device"       "/dev/input/mouse0" 
        #option "device"        "/dev/input/psaux"
        # To config fancy stuff like disable acceleration,
        # put into your .xinitrc something like 'xset m 1 1 &'
EndSection

(And the "AutoServerLayout on" probably makes that reliable )
(also the psaux is not likely

PeteGozz · 2017-07-03 01:35:47

my emphasis added:

ghaverla wrote:

Added evdev to modprobe file. Evdev is loaded (was before too, but I didn't know when). Gpm works on the console. Modinfo evdev shows same thing you have (I was going to say author changed to Admiral Pavel Checkov, United Federation of Planets).

he he..
The mouse works on console !
Well that is excellent
1. hardware / usb OK
2. leaves X and auth system to investigate.

Try to remove this from the journey.
Which I will step through in a separate post if needs be
(in fact the previously mentioned next post

Essentially

kill the login manager (we don't want no broker at the moment)
$ startx

X has mouse ?
1 yes || 2 no

2 If no
try again as root
If still NO mouse cursor then try
apt-get install --reinstall xutils

1 If yes
then its quite probably permissions based
Perhaps an auth step is broken ?
or some console-kit foobar tracking thing is not playing well
Quite frankly it all gets like spaghetti voodoo at X logins with helpful nonsense breaking all over the place.

Try installing lightdm instead of slim ... it has more auth backends

IF *that* makes difference

Please tell this list and bug report slim .

Module evbug does not exist here.

Its a scary and noisy thing best not seen

ghaverla · 2017-07-03 14:00:44

The mode on devtmpfs (searching /proc/mounts) is 755. The permissions on /dev/input/mice is 660 for root/input.

As I haven't tried actually logging in with that graphical GUI login screen, it is slim that is displaying it. The input group has no members listed in /etc/group.

I might have a 30-mouse.conf, but it would be residing in /usr/share (along with others). As libinput originally was processing everything, it would seem that the /usr partition is being mounted early enough for all those x.conf.d snippets in /usr/share to get loaded. There is however, no 30-mouse.conf (or any other mouse.conf) in /usr/share/X11/xorg.conf.d. In /var/log/messages early on in this process, there was a line which suggested the USB mouse was being treated as PS/2.

I am going to stop at this point, as I need to get outside and cut some more hay with a scythe before the dew evaporates away. I'll modify /etc/X11 to not load evdev and try this 30-mouse.conf. Comment #5 not processed yet.

Thanks.

ghaverla · 2017-07-03 15:55:38

/var/log/messages entry
[TS] alyce2 kernel: [time?] mousedev: PS/2 mouse device common for all mice
...
usb 2-5: Product: USB OPTICAL MOUSE
...
input: USB OPTICAL MOUSE as /devices/pci...
hid-generic ... USB OPTICAL MOUSE ...
...
then stuff about disk partitions and btrfs, so /usr is not mounted when the above USB/hid/libinput stuff is happening.

There were 3 boot events in messages, the above commentary is on the first, the other two are seemingly the same. Strictly speaking, the above processes was one where evdev was to be loaded for X to use for the mouse.

Looking in Xorg.log.0, it is back to what the libinput stuff was to bewgin with. It seems all ready to use a mouse, and then you see
config/udev: Add input device USB OPTICAL MOUSE (/dev/input/mouse0)
No input driver specified, ignoring this device.

On to #5.
/etc/init.d/slim stop
startx

X has mouse, and mouse works.

Install lightdm, and set lightdm to manage logins.

Reboot.

GUI screen now has mouse.

I'm guessing at this point, the next thing to try it that PS/2 mouse hint?

ghaverla · 2017-07-03 16:06:54

I had a single user defined. Enter UserID and password for that user, and press login. Back at login prompt.

Enter root for UserID and root's password, and the login completes. Root has a GUI in what appears to be XFCE4.

Get back to text console. Look in /var/log/auth.log

lightdm: pam_unix(lightdm:session) session opened for ****
...
gnome-keyring-daemon[ID]: couldn't create socket directory
couldn't bind to control socket

I will guess, the UID number of this user has changed, and hence it is a permission problem. Nope. No home for user. The /home partition has nothing in it.

mkdir /home/alyce
chown alyce.alyce /home/alyce
chmod 2750 /home/alyce

Attempt to login at GUI again, and it works this time.

PeteGozz · 2017-07-03 16:20:49

ghaverla wrote:

The mode on devtmpfs (searching /proc/mounts) is 755. The permissions on /dev/input/mice is 660 for root/input.

This should not matter as Xorg accesses the devices for users.
With about 2000 qualifications it seems.

ghaverla wrote:

As I haven't tried actually logging in with that graphical GUI login screen, it is slim that is displaying it. The input group has no members listed in /etc/group.

2 "engineering" moments there.
1 By default its "slim" but as you migrated from Debian wheezy it could be whatever you had then.
2 see the Xorg thought above.

ghaverla wrote:

I might have a 30-mouse.conf, but it would be residing in /usr/share (along with others). As libinput originally was processing everything, it would seem that the /usr partition is being mounted early enough for all those x.conf.d snippets in /usr/share to get loaded. There is however, no 30-mouse.conf (or any other mouse.conf) in /usr/share/X11/xorg.conf.d. In /var/log/messages early on in this process, there was a line which suggested the USB mouse was being treated as PS/2.

30-mouse.conf should not be an issue. I just moved all of my /etc/X11/xorg.conf.d out of the way
and my X still works. But please see the end of this.

ghaverla wrote:

I am going to stop at this point, as I need to get outside and cut some more hay with a scythe before the dew evaporates away. I'll modify /etc/X11 to not load evdev and try this 30-mouse.conf. Comment #5 not processed yet.
Thanks.

Its blowing a gale here at the moment and its winter and dark and _nasty_ .

Re: evdev
Dont change anything yet.

try installing slim
ok ? NO then
try lightdm
ok ? no ?
and then
xserver-xorg-legacy
man xwrapper.config

If that dont work I give up, for now
see post #5

-----------------
next life stuff
-----------------

OK so I went on over to the Wayland (Freedesktop) sites. (and stuff)
libinput uses evdev.
Some of the intention is that libinput is a common protocol for wayland and Xorg.

Its essentially "just" a method to exploit the kernels exported interfaces to hardware , under /dev

By plugging the Xserver or Wayland into them. It also speaks evdev. (well the kernel does and libinput sees that fine)

So I went right ahead and broke my X
By installing all of that libinput backend into my system.
Permissions fails and stuff about systemd and lots of noise in the logs...
Nothing worked not even the vesa driver !
NOTE: most of it came from ceres (unstable)
So I guess its the brave new world or something.

Sooooo then ....

I "fixed" that by installing xserver-xorg-legacy
Which goes back to a suid xorg (xorg runs as root)
AND you need to have a Xwrapper.config
which allows use of this dangerous beast.

You probably still have one from wheezy.

So the easy test for installing the xserver-xorg-legacy package would be:

You can startx as root but not as a normal user.
Its worth it as a test in any case.
Which is more or less in my previous post #5 come to think of it .

Now here is the thing:
If it all (mouse and keys) works as root (startx)
AND you can not use keyboard OR login (at the display manager(GUI))

Then tail the logs all you like but I would think that switching login managers is worth a try at least.

There seem to be all sorts of loginkits and handy helper do dbus whatsits breaking insidiously all over the place. These work fine on stable / jessie but it can all get totally silly beyond that..

So you may need a Display Manager that supports more than just pam or more than just loginkit.
I used to trust /etc/X11/default-display-manager (which was just whatever was installed last)
slim used to work here but on stable / jessie . Try slim first.
Then (apparently) lightdm works as it knows about dbus loginkit and pam (it seems).

Or just don't use one at all.
startx or even xinit -- :1

(I dont use one anymore but not for the reasons here)

PeteGozz · 2017-07-03 16:30:00

glad it works now !
Yeah a place to call home is useful and nice thing

For future reference this seems a good drop in point for libinput.
I think I'm going to need it again.

https://wayland.freedesktop.org/libinpu … pages.html

Last edited by PeteGozz (2017-07-03 16:33:35)

ghaverla · 2017-07-03 17:29:45

There shouldn't have been any Debian/Jessie or Debian/Wheezy hanging around, this was a Devuan/Jessie install upgraded to Ascii. I guess I didn't introduce that well enough. At some point, I will move over the contents of /home (which was Debian/Jessie).

I will try to get back to this later today, to see what else I can learn.

It is height of summer here. I am considerably further away from the equator than you are (I am at 56N - Dawson Creek, BC, Canada, where the Alaska Highway begins), and I see Adelaide is at 34S. So you are somewhere in the 30's S latitude. I live about 5 miles downwind of a wind farm (130 MW?), and today is windy as well.

Thanks for the help.

PeteGozz · 2017-07-03 17:49:44

Hey cool.
Happy 150th Canadian Cuzzes

Man 56 N that is insanely _way_ too close to any pole.
You guys must be born with glycol for blood or something.
I apologise for saying its cold. Its not even 0
Its also windy here.
Been gusting up to 100kmh in some places.

Our state is running over on 60% (ish) wind power right now.
But I diverge digress and disintegrate
(and way off topic)

I re-learnt some stuff I should know better about and learnt some new stuff.
So if it was help then even better.

The officially official Devuan Forum!

#1 2017-07-02 14:14:58

New (ascii from jessie) install, mouse not working

#2 2017-07-02 16:05:31

Re: New (ascii from jessie) install, mouse not working

#3 2017-07-02 22:52:42

Re: New (ascii from jessie) install, mouse not working

#4 2017-07-03 01:06:17

Re: New (ascii from jessie) install, mouse not working

#5 2017-07-03 01:35:47

Re: New (ascii from jessie) install, mouse not working

#6 2017-07-03 14:00:44

Re: New (ascii from jessie) install, mouse not working

#7 2017-07-03 15:55:38

Re: New (ascii from jessie) install, mouse not working

#8 2017-07-03 16:06:54

Re: New (ascii from jessie) install, mouse not working

#9 2017-07-03 16:20:49

Re: New (ascii from jessie) install, mouse not working

#10 2017-07-03 16:30:00

Re: New (ascii from jessie) install, mouse not working

#11 2017-07-03 17:29:45

Re: New (ascii from jessie) install, mouse not working

#12 2017-07-03 17:49:44

Re: New (ascii from jessie) install, mouse not working

Board footer