Hello:

I have found Leafpad to be, although usupported, really very good and lightweight.
Deserves a better fate ...

I found the solution here:

https://forum.lxde.org/viewtopic.php?t=36196#p47860

In my case, I just opened the launcher: Applications -> Accesories -> right-click on Leafpad to edit.

Changed the command line from leafpad %f to leafpad --codeset UTF-8 %f and saved.

Now, everytime I open a text file, it will save the document with the UTF-8 codeset by default.
It just happens that the hard coded default is ANSI_X3.4-1968, no bug to splat! there.    =^D 

Cheers,

A.

Hello:

No, had not thought of looking there.

To check, I opened the .xsession-errors file, took note of the last entry line number and closed it.
Then I opened FF, generated the error and reopened .xsession-errors.

These are the new lines generated:

Xlib:  extension "RANDR" missing on display ":0.0".
Xlib:  extension "RANDR" missing on display ":0.0".
1540594962814 addons.webextension.{5657c026-efc3-4860-b43b-16e4eaa8a9aa} WARN Please specify whether you want browser_style or not in your browser_action options.
1540594962832 addons.webextension.jid1-MnnxcxisBPnSXQ@jetpack WARN Please specify whether you want browser_style or not in your browser_action options.
Xlib:  extension "RANDR" missing on display ":0.0".
Xlib:  extension "RANDR" missing on display ":0.0".
Xlib:  extension "RANDR" missing on display ":0.0".
Xlib:  extension "RANDR" missing on display ":0.0".

The Xlib: lines are all over the place, I'd say over 75% of the file content is that specific line.
RANDR is disabled by the Nvidia proprietary drivers so it has a well known cause.     

groucho@devuan:~$ cat /var/log/Xorg.0.log | grep -i RANDR
[    34.234] (WW) NVIDIA: Xinerama is enabled, so RandR has likely been disabled by the
[    37.011] (WW) NVIDIA(0): Not registering RandR
[    37.011] (==) RandR enabled
[    37.100] (WW) NVIDIA(1): Not registering RandR
[    37.100] (==) RandR enabled
[    37.315] (WW) NVIDIA(2): Not registering RandR
[    37.315] (==) RandR enabled
groucho@devuan:~$ 

The other new lines are of evident browser/add-on origin

addons.webextension.{5657c026-efc3-4860-b43b-16e4eaa8a9aa} WARN Please specify whether you want browser_style or not in your browser_action options.
addons.webextension.jid1-MnnxcxisBPnSXQ@jetpackn WARN Please specify whether you want browser_style or not in your browser_action options.

I have a few addons in FF:

Calomel SSL Validation
No Coin
Privacy Badger
Squared Australis Tabs
UBlock Origin
YouTube ALL HTML5
YouTube Flash Player

When I searched the web for the 5657c026-efc3-4860-b43b-16e4eaa8a9aa, I came up with a apge with this mention:

---
Name: No Coin - Block miners on the web!
Version: 0.4.14
Enabled: true
ID: {5657c026-efc3-4860-b43b-16e4eaa8a9aa}
---

So I tried disabling No Coin to see if the problem went away but no, that did not keep the problem from happening.

A search for the jid1-MnnxcxisBPnSXQ@jetpackn string did not come up with an exact match, but I found partial matches and they are all linked to the Privacy Badger add-on.

Then I tried disabling Privacy Badger to see if the problem went away but no, that did not keep the problem from happening either. 

I then, tired of all this, disabled all the addons I have installed in FF, but still no cigar.  =^/

Will have to keep looking.
But where?

Thanks a lot for your input.

Best,

A.

Hello:

Thanks for the tip, I did not know about that app.

But that's not the problem as both Devuan ASCII and X Server probe and detect the mouse properly:

groucho@devuan:~$ lsusb
Bus 010 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 005: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 007 Device 004: ID 046d:c077 Logitech, Inc. M105 Optical Mouse
--- snip ---
groucho@devuan:~$ 

groucho@devuan:~$ cat /var/log/Xorg.0.log | grep -i mouse
[    38.133] (II) config/udev: Adding input device Logitech USB Optical Mouse (/dev/input/event4)
[    38.133] (**) Logitech USB Optical Mouse: Applying InputClass "evdev pointer catchall"
[    38.133] (**) Logitech USB Optical Mouse: Applying InputClass "libinput pointer catchall"
[    38.133] (II) Using input driver 'libinput' for 'Logitech USB Optical Mouse'
[    38.133] (**) Logitech USB Optical Mouse: always reports core events
[    38.192] (II) input device 'Logitech USB Optical Mouse', /dev/input/event4 is tagged by udev as: Mouse
[    38.192] (II) input device 'Logitech USB Optical Mouse', /dev/input/event4 is a pointer caps
[    38.224] (II) XINPUT: Adding extended input device "Logitech USB Optical Mouse" (type: MOUSE, id 10)
[    38.224] (**) Logitech USB Optical Mouse: (accel) selected scheme none/0
[    38.224] (**) Logitech USB Optical Mouse: (accel) acceleration factor: 2.000
[    38.224] (**) Logitech USB Optical Mouse: (accel) acceleration threshold: 4
[    38.284] (II) input device 'Logitech USB Optical Mouse', /dev/input/event4 is tagged by udev as: Mouse
[    38.284] (II) input device 'Logitech USB Optical Mouse', /dev/input/event4 is a pointer caps
[    38.284] (II) config/udev: Adding input device Logitech USB Optical Mouse (/dev/input/mouse1)
groucho@devuan:~$ 

Thanks for your input.

A.

Hello:

I seriously doubt that it's something the Debian crowd wants, just the opposite.
And as long as that Pottering fellow is at the helm, it will stay that way.

Indeed it does.

As I have made clear in other posts, I'm not a developer.
I just have 20+ years of IT work, both at home and in my profession, with a hands on approach to software and hardware save programming anything but simple batch routines.

Systemd in Linux brings back memories of my transition from W3.11 to W95, with the end of *.ini files I understood to the undocumented workings of *the registry*, which took me years to get a minimal hold of as it was constantly changing and going deeper and deeper into the OS with every iteration and as a result, the end of any chance of knowing/controlling what was going on.

The registry in Windows OSs is a virus and I see systemd as nothing more than a registry class virus infecting Linux_land.

There are people both inside and outside IT that actually want this and are quite willing to pay shitloads of money for it to happen.

Call me paranoid but I don't see this MS cozying up to Linux in various ways lately as a coincidence: these things do not happen just because or on a senior manager's whim.
What I do see (YMMV) is systemd being a sort of convergence of Linux with Windows, which will not be good for Linux and may well be its undoing.

But I also think that the options virtue of the Linux world (which has been spread far too thinly, IMO) will one day be its undoing.

Like I wrote once, elsewhere:

Sorry for the rant.

Cheers,

A.

Hello:

If you mean the Edit -> Preferences -> Behaviour -> Navigation -> Single click to activate items in Thunar, no ...
I had not thougth of that one.

I use it quite a lot, one of the first things I used to set up everytime I installed an OS, that and the type repeat settings in BIOS.

I recall (waaay back when) when it was the new thing through some special add-on software that only came with the (expensive) MS-Intellimouse.
I was delighted with that as well as with being able to go off one edge of the screen to appear at the other edge.   
So young ...

But it is only supposed to affect left button behaviour.

Now, if you mean what I do when I right-click on a link, I just do a single click, not a double click.

Let's see if the new setting makes things better and wait for the rest of the affected parties to report.

Thanks for your input.

Cheers,

A.

Hello:

Some of my best mice are PS2.   8^D

Yes!
That apparently did the trick.   =-)

I set them at:
-> Double Click Time = 425 ms
-> Double Click Distance = 5 px

It seems that if the Double Click Time is too short, it behaves like a single click, not only at the Left Button but at the Right Button also
Shouldn't work that way.

Isn't Double Click an action assigned only to the left button?
Then why would Double Click Time affect how the right button responds to input?

I think that may be where the source of the problem is.

In any case, the problem (at least for me) seems to have gone away.
As long as I don't need a shorter Double Click Time, it will be in check.

I'd appreciate it if other forum members with the same problem tried the settings I have used and see if it goes away for them too.

Thanks a lot for your input.

Best,

A.

Hello:

Aha! Now there's four of us.

I see ...
That narrows the possible origin of the problem quite a bit.

Yes, seems to be the same.

It gets on my nerves, particularly when it happens in the browser and when I need to copy/paste something.
Very annoying.

Anyone have any idea as to how it can be fixed?

Thanks for your input.

A.

Hello:

Quite so ...  8^ o
Thanks - duly noted and corrected.

Seems so.

The pop-up menu is displayed as long as I hold down the right mouse button.
If I let it go, the menu recedes. 

Yes.
I right-click (at this point the pop-up menu should stay open, but it does not).
Like the previous example, the pop-up menu is displayed as long as I hold down the right mouse button.
If I let it go, the menu recedes. 

I think I have seen some strange behaviour in other apps, but it is in the browser where it is  most annoying.

I seem to recall having experienced this but I can's say much more.

Well, at least it's not just me.

It has happened with three different pointing devices: the first one, a PS/2 mouse, a very solid + well made Wise edition, the second a crappy plasticky Verbatim and the actual one a brand new Logitech M100, all optical.

All three exhibited the exact same behaviour, so IMO it's definitely not a mouse thing.

Maybe it's something to do with the mouse drivers (?) selected by the default X server settings through udev (I think that's how it works).

Thanks for your input.

Cheers,

A.

Hello:

Indeed it is.
Thanks.

Couldn't be that it did/did not work.
Something was surely amiss somewhere.

I'll drop the OP a line thanking hin for taking the time to find out what was up.

Don't we have a sticky section where these things can go and live forever?

One thing I found was that there was some sort of issue with the Wise PS2 mouse that I had plugged into my Wise USB keyboard.

Once I found the crap Verbatim USB mouse, the problem with the mouse freezing went away.
I'll get a decent mouse tomorrow ...

But I really have to brush up my cuasi non-existent keyboard skills, it's unacceptable that a bad mouse can ground you.

In any case, it seems that part of the problem was related to /dev/mouse0 not being there and the existence of /dev/psaux but I decided to give up on that.
It's probably an evdev configuration issue.

So, this is what I did:

1.
Edited xorg.conf and deleted all InputDevice entires in Section "ServerLayout" and the two "InputDevice" Sections.
X server probes and picks up what is there.

2.
Made sure that Section Section "ServerFlags" has these options to the default settings.

Section "ServerFlags"
    Option         "DontZap" "False"                # default False - "True" disables <Ctrl><Alt><BS> (server abort)
    Option         "AutoAddDevices" "True"      # default True - to use system kb, kb layout and mouse settings
    Option         "AutoEnableDevices" "True"  # default True - if "AutoAddDevices" is set to default 
EndSection

Of course, being default settings you can do away with the whole "ServerFlags" section but I have decided to keep them so I remember all this.

groucho@devuan:~$ setxkbmap -query
rules:      evdev
model:      pc105
layout:     es
variant:    deadtilde
options:    lv3:ralt_switch,terminate:ctrl_alt_bksp
groucho@devuan:~$ 

Now Control+Alt+Backspace works as well as Control+Alt+Fx.

Really don't need the special characters or accented characters in Terminal (ç Ç ñ Ñ - ' ` ^ " ) but there's an issue with Leafpad and codeset=ANSI_X3.4-1968 which I will adress in another post.

Maybe we're on a roll and we'll solve it?   =-)

Cheers,

A.

Hello:

Here's my xorg.conf settings for input devices:

Section "ServerLayout"
Identifier     "Layout0"
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
EndSection

Section "InputDevice"
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection

Section "InputDevice"
    # generated from default configuration
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/psaux"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5" 
EndSection

Section "ServerFlags"
    Option         "DontZap" "False"             # default False - "True" disables <Ctrl><Alt><BS> (server abort)
    Option         "AutoAddDevices" "False"      # default True - to use system kb, kb layout and mouse settings
    Option         "AutoEnableDevices" "True"    # default True - 
EndSection

If I check the box that says Use system defaults in Applications -> Settings -> Keyboard -> Layout + logou/login, I end up getting what seems to be a US layout on both X and the terminal and Control+Alt+Backspace will not terminate the X server.

But if I change the "AutoAddDevices" to "True" (so that it does what it is supposed to do), my mouse freezes BUT Control+Alt+Backspace works as advertised.   

Shutting down the server in these conditions does not do anything for me, I have to resort to Ctrl+Alt+F1 th sudo jed the xorg.conf file so I can have a working mouse again.

I'll have a look.

Thanks for your input.

Cheers,

A.

Hello:

Hmm ...
I think not.

I'm on ASCII and if I set up an xorg.conf (default setting enables ctrl-alt-backspace) and do Applications -> Settings -> Keyboard -> Layout, where the Use system defaults box is checked, it will work but I've been at odds with setting layouts and kbd for the longest while so I go the Xfce route.

ie: in Section "ServerFlags"
Option "DontZap" set to "False" (default "False")  - "True" setting disables <Ctrl><Alt><BS> (server abort)
Option "AutoAddDevices" set to "True" (default "True")  - "True" setting is for using system kb, kb layout and mouse settings

So, my guess is that if it does not work in ASCII it's not because of the kernel version but because of the Xfce plugin or something else related to the Kb settings in Xfce.

I'll try that.
I never used ctrl-alt-backspace much but when I learned how convenient it was, I found it very useful.

I think it should be fixed/reinstated - as it does work.

Yes it is.

Thta's what I am using.
Probably the source of the ctrl-alt-backspace problem.

Thanks for your input.

Cheers,

A.