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.

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.

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

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.

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.

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.

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)

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.

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?

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.

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 .

Its a scary and noisy thing best not seen

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

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

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.

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

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.