Switch user causes screen to go blank

[C.T.F. Jansen]

Greetings,

When ones does a switch user from the application launch button then the 
screen goes blank and it stays that way until re-booted.

This seems to have been introduced in Debian 12.

Looking around there is no fix to this, only work arounds of varying 
effectiveness.


One work around is to do a command line

xdg-screensaver lock

There might be something one can click on somewhere to have the same effect.

With this I've so far been able to start another session without loosing 
anything.
To go back to the first login I had to do a ctrl-alt-f2 then back using 
ctrl-alt-f7.


This is a bug. It needs to be fixed.

Initiate a screen saver lock then hack away at ctrl-alt-whatever until 
one has by-passed the "issues".


If there's a better way or actual fix one would interested to know about it.

Cheers

frank.jan...@actrix.gen.nzZl2TTS

Re: Debian does not load zfs automatically at boot and strange messages displayed on the screen...

[DdB]

Am 30.04.2024 um 16:48 schrieb Mario Marietto:
> Probably this is not the proper method to do it ?
Done it in vm's and on bare metal many times. Never ran into your kind
of problems. :-(

Here is the guide, i suggest:
https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/index.html#installation

Debian does not load zfs automatically at boot and strange messages displayed on the screen...

[Mario Marietto]

Hello to everyone.

I've just installed Debian 12 (netinstall version with ssh server + web
server) as guest os on top of Windows 11 using qemu + whpx. These are the
parameters that I've used :


I:\OS\vms\qemu\qemu-system-x86_64.exe -machine q35 -accel whpx -cpu
kvm64,hv_relaxed,hv_time,hv_synic -m 8G -vga std -audiodev dsound,id=snd0
-device ich9-intel-hda -device hda-duplex,audiodev=snd0 -hda
"I:\Backup\Linux\Debian.img" -drive file=\\.\PhysicalDrive5 -drive
file=\\.\PhysicalDrive6 -drive file=\\.\PhysicalDrive8 -rtc base=localtime
-device usb-ehci,id=usb,bus=pcie.0,addr=0x3 -device usb-tablet -device
usb-kbd -smbios type=2 -nodefaults -netdev user,id=net0 -device
e1000,netdev=net0,id=net0,mac=52:54:00:11:22:33 -device ich9-ahci,id=sata
-bios "I:\OS\vms\qemu\OVMF_combined.fd"


Actually it has two problems :

1) I've added the module zfs to /etc/modules because I want to autoload zfs
as soon as Debian makes the booting,but it does not work. Probably this is
not the proper method to do it ?

2) As you can see on the attached picture,I see a lot of strange messages
on the screen ; I don't understand why they happen,but I would like to
suppress them.

[image: 2024-04-30 16 42 44.png]

-- 
Mario.

Re: Re: Issue with USB External Keyboard, External Mouse, and Screen Brightness on Dell Laptop

[Marcelo Laia]

10,916 V looks a bit odd to me.


After your comments, I looking forward about the battery voltage and I
found this:

https://www.linkedin.com/pulse/how-choose-laptop-battery-king-sener/

"Voltage is closely related to the number of cells in the battery -
typically a 10.8V battery has 6 cells and a 14.4V battery has 8 cells."


https://superuser.com/questions/33207/laptop-battery-is-voltage-really-important-to-respect

https://superuser.com/a/406492

"The first stage is adapter which is nearly 5 V higher than the battery
rating voltage to charge it faster to the full. Now the second stage is
the motherboard or processor which typically runs at 5 V and for that
you have voltage regulator inside."

At 98%, the voltage here is:

  battery
present: yes
rechargeable:yes
state:   charging
warning-level:   none
energy:  36,0417 Wh
energy-empty:0 Wh
energy-full: 36,3858 Wh
energy-full-design:  59,94 Wh
energy-rate: 1,8537 W
voltage: 12,734 V
charge-cycles:   N/A
time to full:11,1 minutes
percentage:  99%
capacity:60,7037%
technology:  lithium-ion
icon-name:  'battery-full-charging-symbolic'

I found that this battery I bought in 2019. However, it is pretty good
yet!


--
Marcelo

Re: Re: Issue with USB External Keyboard, External Mouse, and Screen Brightness on Dell Laptop

[hw]

Is it possible that the USB ports do not supply power once the laptop
is running on battery?

Does the NumLock LED of the keyboard go out?


On Thu, 2024-02-22 at 13:49 -0300, Marcelo Laia wrote:
> Dear Debian Users,
> 
> Thank you all for the invaluable assistance provided. Unfortunately, the 
> issue has resurfaced today. I don't believe it's related to the age of the 
> hardware, although my Inspiron 5547-A20 is from 2014, as indicated below:
> 
> Inspiron 5547 01 OCT. 2014
> 
> Some hardware details:
> 
> - BIOS:
>- Vendor: Dell Inc.
>- Version: A13
>- Date: 05/27/2019
> - CPU:
>- Product: Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz
> - Memory:
>- Size: 16GB
> 
> Today, the battery still had 66% charge when this strange problem occurred. 
> It's worth mentioning that in all these days, between my last post here on 
> the list and today, I always use the battery until it reaches between 20-10%, 
> at which point I plug in the charger and let it charge until it reaches 
> 95-100%.
> 
> I ran the following commands:
> 
> With the power cable plugged into the power grid, i.e., the battery is 
> charging:
> 
> :~$ sudo lsusb -t
> 
> /:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/2p, 480M
>  |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/8p, 480M
>  |__ Port 005: Dev 003, If 0, Class=Wireless, Driver=btusb, 12M
>  |__ Port 005: Dev 003, If 1, Class=Wireless, Driver=btusb, 12M
>  |__ Port 006: Dev 004, 12M
>  |__ Port 007: Dev 005, If 0, Class=Vendor Specific Class, 
> Driver=rtsx_usb, 480M
>  |__ Port 008: Dev 006, If 0, Class=Video, Driver=uvcvideo, 480M
>  |__ Port 008: Dev 006, If 1, Class=Video, Driver=uvcvideo, 480M
> /:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/9p, 480M
>  |__ Port 002: Dev 007, If 0, Class=Human Interface Device, 
> Driver=usbhid, 1.5M
> /:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 5000M
> :~$
> 
> :~$ ls /sys/bus/usb/drivers/usb/
> 1-1  1-1.5  1-1.6  1-1.7  1-1.8  2-2  bind  module  uevent  unbind  usb1  
> usb2  usb3
> :~$ 
> 
> After unplugging the power cable, i.e., the battery is discharging:
> 
> After a few seconds, the screen brightness is set to zero. The mouse remains 
> active, and I can use it for a few more seconds, when it also becomes 
> disabled. From then on, only the touchpad and internal keyboard are 
> functional.
> 
> :~$ sudo lsusb -t
> 
> /:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/2p, 480M
>  |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/8p, 480M
>  |__ Port 005: Dev 003, If 0, Class=Wireless, Driver=btusb, 12M
>  |__ Port 005: Dev 003, If 1, Class=Wireless, Driver=btusb, 12M
>  |__ Port 006: Dev 004, 12M
>  |__ Port 007: Dev 005, If 0, Class=Vendor Specific Class, 
> Driver=rtsx_usb, 480M
>  |__ Port 008: Dev 006, If 0, Class=Video, Driver=uvcvideo, 480M
>  |__ Port 008: Dev 006, If 1, Class=Video, Driver=uvcvideo, 480M
> /:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/9p, 480M
> /:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 5000M
> :~$ 
> 
> ~$ ls /sys/bus/usb/drivers/usb/
> 1-1  1-1.5  1-1.6  1-1.7  1-1.8  bind  module  uevent  unbind  usb1  usb2  
> usb3
> :~$ 
> 
> :~$ echo '2-2' | sudo tee /sys/bus/usb/drivers/usb/bind 
> 2-2
> tee: /sys/bus/usb/drivers/usb/bind: No device
> :~$ 
> 
> :~$ upower --dump
> Device: /org/freedesktop/UPower/devices/line_power_ACAD
>native-path:  ACAD
>power supply: yes
>updated:  qui 22 fev 2024 13:23:50 (182 seconds ago)
>has history:  no
>has statistics:   no
>line-power
>  warning-level:   none
>  online:  no
>  icon-name:  'ac-adapter-symbolic'
> 
> Device: /org/freedesktop/UPower/devices/battery_BAT1
>native-path:  BAT1
>vendor:   SANYO
>model:DELL WYT3M94Q
>serial:   0038
>power supply: yes
>updated:  qui 22 fev 2024 13:26:31 (21 seconds ago)
>has history:  yes
>has statistics:   yes
>battery
>  present: yes
>  rechargeable:yes
>  state:   discharging
>  warning-level:   none
>  energy:  23,9982 Wh
>  energy-empty:0 Wh
>  energy-full: 36,4857 Wh
>  energy-full-design:  59,94 Wh
>  energy-rate: 30,0588 W
>  voltage: 10,916 V
>  charge-cycles:   N/A
>  time to empty:   47,9 minutes

Re: Issue with USB External Keyboard, External Mouse, and Screen Brightness on Dell Laptop

[David Wright]

On Thu 22 Feb 2024 at 13:49:54 (-0300), Marcelo Laia wrote:

> Inspiron 5547 01 OCT. 2014
> 
> Some hardware details:
> 
> - BIOS:
>   - Vendor: Dell Inc.
>   - Version: A13
>   - Date: 05/27/2019
> - CPU:
>   - Product: Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz
> - Memory:
>   - Size: 16GB

[ … ]

> After unplugging the power cable, i.e., the battery is discharging:
> 
> After a few seconds, the screen brightness is set to zero. The mouse
> remains active, and I can use it for a few more seconds, when it
> also becomes disabled. From then on, only the touchpad and internal
> keyboard are functional.

[ … ]

> Any other suggestions? It seems to me that it's not related to
> power, however, what is the specific list for energy-related issues? 

My advice would be to prepare for a day when you see nothing from
the moment you switch it on.

Here's a log of what happened with my Dell D430 laptop, purchased in
2008 as a stop-gap, acquired by me in 2009. First the battery packs:

  2014-02-12 Large battery started to go bad. Charging light started
  constantly flashing a pattern: four yellows and a longer
  green. Apart from that, everything works ok: the battery stays at
  five lights, and the acpi variables all show sensible
  values. However, the battery discharges much more quickly than it
  should, particularly early on, so some cells probably don't work
  properly.

  2015-03-29 Started to switch itself off when the power cable was
  disconnected. It appears that the battery is not actually connected
  to the computer when this happens.

  2015-03-31 The large battery finally gave up. When the charge button
  is pressed, only LEDS 1, 3 and 5 light up, but flashing. Otherwise,
  dead. Disposed of the large battery in Best Buy's foyer and started
  using the small one.

And the screen:

  2011-10-21 Started to switch itself off unaccountably every so
  often. No freeze, no kernel panic, but just like holding down the
  power switch. It will have been running a while, and usually it
  happens when the machine or lid is moved.

  2017-01-22 After a day or two of slight flickering in brightness,
  the screen blanked out a few times during the day. The machine was
  still running, and so X could be quit and restarted, and rebooted
  too. The screen would come back, but often disappear almost
  immediately, even while the Dell splash screen was being displayed
  at switch-on. It went away entirely the same day.

  2018-06-19 After being depowered for a week, the battery capacity
  had fallen to 2%. However, on AC the screen started working again,
  though it just flickered a little all the time. Took the opportunity
  to demote Internal HDD to below USB and Optical Drive in the BIOS.
  Got about three minutes before it reverted.

  2020-04-16 Started to crash, and eventually failed to boot.
  Obviously difficult to diagnose when there's no display at power-on,
  so scrapped.

If you're wondering why I kept it so long, I could use an external
monitor to display its X server screen, but neither the BIOS nor
the console would work that way, so I had to type blind until I got
into X. With a 30 second countdown, I could operate the Grub screen
blind. I also managed to install buster in text mode by copying what
I typed while installing on another PC at the same time. (I might
have been able to clone jessie into the other partition, but that
would have then required two dist-upgrades.)

Cheers,
David.

Re: Issue with USB External Keyboard, External Mouse, and Screen Brightness on Dell Laptop

[Charles Curley]

On Thu, 22 Feb 2024 13:49:54 -0300
Marcelo Laia  wrote:

> Thank you all for the invaluable assistance provided. Unfortunately,
> the issue has resurfaced today. I don't believe it's related to the
> age of the hardware, although my Inspiron 5547-A20 is from 2014, as
> indicated below:

A stab in the dark:

I take it that you ran the upower --dump command while the battery was
discharging. 10,916 V looks a bit odd to me. What does a dump show when
the battery is fully charged? I wonder if that voltage is too low to
support the laptop.

My two ancient Lenovos (2011 and 2012) are both showing much better
values than that.

The difference between the energy-full and energy-full-design values,
and the capacity both lead me to wonder if it isn't time to buy a new
battery (or maybe a new or refurbished laptop).

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Re: Issue with USB External Keyboard, External Mouse, and Screen Brightness on Dell Laptop

[Marcelo Laia]

Dear Debian Users,

Thank you all for the invaluable assistance provided. Unfortunately, the issue 
has resurfaced today. I don't believe it's related to the age of the hardware, 
although my Inspiron 5547-A20 is from 2014, as indicated below:

Inspiron 5547 01 OCT. 2014

Some hardware details:

- BIOS:
  - Vendor: Dell Inc.
  - Version: A13
  - Date: 05/27/2019
- CPU:
  - Product: Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz
- Memory:
  - Size: 16GB

Today, the battery still had 66% charge when this strange problem occurred. 
It's worth mentioning that in all these days, between my last post here on the 
list and today, I always use the battery until it reaches between 20-10%, at 
which point I plug in the charger and let it charge until it reaches 95-100%.

I ran the following commands:

With the power cable plugged into the power grid, i.e., the battery is charging:

:~$ sudo lsusb -t

/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/8p, 480M
|__ Port 005: Dev 003, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 005: Dev 003, If 1, Class=Wireless, Driver=btusb, 12M
|__ Port 006: Dev 004, 12M
|__ Port 007: Dev 005, If 0, Class=Vendor Specific Class, 
Driver=rtsx_usb, 480M
|__ Port 008: Dev 006, If 0, Class=Video, Driver=uvcvideo, 480M
|__ Port 008: Dev 006, If 1, Class=Video, Driver=uvcvideo, 480M
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/9p, 480M
|__ Port 002: Dev 007, If 0, Class=Human Interface Device, Driver=usbhid, 
1.5M
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 5000M
:~$

:~$ ls /sys/bus/usb/drivers/usb/
1-1  1-1.5  1-1.6  1-1.7  1-1.8  2-2  bind  module  uevent  unbind  usb1  usb2  
usb3
:~$ 


After unplugging the power cable, i.e., the battery is discharging:

After a few seconds, the screen brightness is set to zero. The mouse remains 
active, and I can use it for a few more seconds, when it also becomes disabled. 
From then on, only the touchpad and internal keyboard are functional.

:~$ sudo lsusb -t

/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/8p, 480M
|__ Port 005: Dev 003, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 005: Dev 003, If 1, Class=Wireless, Driver=btusb, 12M
|__ Port 006: Dev 004, 12M
|__ Port 007: Dev 005, If 0, Class=Vendor Specific Class, 
Driver=rtsx_usb, 480M
|__ Port 008: Dev 006, If 0, Class=Video, Driver=uvcvideo, 480M
|__ Port 008: Dev 006, If 1, Class=Video, Driver=uvcvideo, 480M
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/9p, 480M
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 5000M
:~$ 


~$ ls /sys/bus/usb/drivers/usb/
1-1  1-1.5  1-1.6  1-1.7  1-1.8  bind  module  uevent  unbind  usb1  usb2  usb3
:~$ 

:~$ echo '2-2' | sudo tee /sys/bus/usb/drivers/usb/bind 
2-2

tee: /sys/bus/usb/drivers/usb/bind: No device
:~$ 


:~$ upower --dump
Device: /org/freedesktop/UPower/devices/line_power_ACAD
  native-path:  ACAD
  power supply: yes
  updated:  qui 22 fev 2024 13:23:50 (182 seconds ago)
  has history:  no
  has statistics:   no
  line-power
warning-level:   none
online:  no
icon-name:  'ac-adapter-symbolic'

Device: /org/freedesktop/UPower/devices/battery_BAT1
  native-path:  BAT1
  vendor:   SANYO
  model:DELL WYT3M94Q
  serial:   0038
  power supply: yes
  updated:  qui 22 fev 2024 13:26:31 (21 seconds ago)
  has history:  yes
  has statistics:   yes
  battery
present: yes
rechargeable:yes
state:   discharging
warning-level:   none
energy:  23,9982 Wh
energy-empty:0 Wh
energy-full: 36,4857 Wh
energy-full-design:  59,94 Wh
energy-rate: 30,0588 W
voltage: 10,916 V
charge-cycles:   N/A
time to empty:   47,9 minutes
percentage:  65%
capacity:60,8704%
technology:  lithium-ion
icon-name:  'battery-full-symbolic'
  History (charge):
1708619191  65,000  discharging
1708619161  66,000  discharging
1708619101  67,000  discharging
  History (rate):
1708619101  30,059  discharging

Device: /org/freedesktop/UPower/devices/DisplayDevice
  power supply: yes
  updated:  qui 22 fev 2024 13:26:31 (21 seconds ago)
  has history:  no
  has statistics:   no
  battery
present: yes
state:   discharging
warning-level:   none
energy:  23,9982 Wh
energy-full: 36,4857 Wh
energy-rate: 30,0588 W
charge-cycles:   N/A
time to empty:   47,9 minutes
percentage

Re: Issue with USB External Keyboard, External Mouse, and Screen Brightness on Dell Laptop

[Max Nikulin]

On 15/02/2024 12:39, David Wright wrote:


I would go further than tomas, and suggest that the battery might be
suspect, or the charging circuit of course. (None of my three laptops
works without AC power.) How old is it?


Battery health may be estimated from output of

 upower --dump

by comparison energy-full-design, energy-full, and other values.

I still believe it is excessively aggressive power settings in GNOME or 
in firmware (BIOS) setup. Maybe it is result of shooting own foot by 
tools like powertop or tlp. Anyway it is rather wrong settings than 
wrong behavior. There is a chance that the issue is with USB controller 
driver. Likely it is better to ask the same question in a user group 
more specific to power management.

Re: Issue with USB External Keyboard, External Mouse, and Screen Brightness on Dell Laptop

[David Wright]

On Wed 14 Feb 2024 at 20:09:09 (-0300), Marcelo Laia wrote:
> Unfortunately, the issue has worsened. Today, I observed that upon unplugging 
> the power cable, within one or two seconds, the screen dims (brightness is 
> set to zero), and both the external mouse and keyboard (USB) stop working. 
> Even if I try to use the keyboard or mouse, they do not reactivate. Only the 
> laptop's internal touchpad and keyboard continue to function. When I 
> reconnect the power cable, both the external mouse and keyboard resume 
> working automatically. However, I need to manually adjust the screen 
> brightness. I have not installed the usbguard package. Could there be another 
> underlying cause?

I would go further than tomas, and suggest that the battery might be
suspect, or the charging circuit of course. (None of my three laptops
works without AC power.) How old is it?

Cheers,
David.

Re: Re: Issue with USB External Keyboard, External Mouse, and Screen Brightness on Dell Laptop

[Marcelo Laia]

Dear Debian community,

Thank you for your insights. Unfortunately, the issue has worsened. Today, I 
observed that upon unplugging the power cable, within one or two seconds, the 
screen dims (brightness is set to zero), and both the external mouse and 
keyboard (USB) stop working. Even if I try to use the keyboard or mouse, they 
do not reactivate. Only the laptop's internal touchpad and keyboard continue to 
function. When I reconnect the power cable, both the external mouse and 
keyboard resume working automatically. However, I need to manually adjust the 
screen brightness. I have not installed the usbguard package. Could there be 
another underlying cause?

Best regards,

--
Marcelo

Re: Issue with USB External Keyboard, External Mouse, and Screen Brightness on Dell Laptop

[Max Nikulin]

On 24/01/2024 02:13, Marcelo Laia wrote:


After recently upgrade, my external keyboard and external mouse (both 
USB) stopped working after after the screen brightness automatically 
decreased. This has occurred a few times, and I can only solve it by 
rebooting the laptop.


Were your experimenting with energy saving tools (desktop environment 
GUI, powertop, tlp, etc.)?


jan 23 11:28:43 marcelo dbus-daemon[2019]: [session uid=1000 pid=2019] 
Activating service name='org.gnome.ScreenSaver' requested by ':1.65' 
(uid=1000 pid=2729 comm="/usr/libexec/gsd-usb-protection")
jan 23 11:28:43 marcelo gsd-usb-protect[2729]: Failed to fetch USBGuard 
parameters: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The 
name org.usbguard1 was not provided by any .service files


I have no idea what gsd-usb-protection should do or whether GNOME 
expects installed usbguard, but it might be related.

Re: Issue with USB External Keyboard, External Mouse, and Screen Brightness on Dell Laptop

[tomas]

On Tue, Jan 23, 2024 at 04:13:23PM -0300, Marcelo Laia wrote:
> Dear Debian community,
> 
> I am facing an issue with my Dell laptop, running Debian.
> 
> After recently upgrade, my external keyboard and external mouse (both USB)
> stopped working after after the screen brightness automatically decreased.
> This has occurred a few times, and I can only solve it by rebooting the
> laptop.
> 
> Furthermore, I have observed that the issue is also related to the behavior
> of screen brightness, which seems to decrease automatically.

A shot in the dark: does that happen only when running from battery?

Perhaps the laptop is powering down its (internal) USB hub to save
battery charge. In some BIOSes there are knobs to control this.

Cheers
-- 
t


signature.asc
Description: PGP signature

Issue with USB External Keyboard, External Mouse, and Screen Brightness on Dell Laptop

[Marcelo Laia]

Dear Debian community,

I am facing an issue with my Dell laptop, running Debian.

After recently upgrade, my external keyboard and external mouse 
(both USB) stopped working after after the screen brightness 
automatically decreased. This has occurred a few times, and I can 
only solve it by rebooting the laptop.


Furthermore, I have observed that the issue is also related to 
the behavior of screen brightness, which seems to decrease 
automatically.


Disconnecting and reconnecting the devices does not solve the problem.

Any guidance or suggestions would be welcome.

I found related problem at the internet.

https://bbs.archlinux.org/viewtopic.php?id=291592

https://bbs.archlinux.org/viewtopic.php?id=291555

https://bbs.archlinux.org/viewtopic.php?id=291931

:~$ uname -a
Linux marcelo 6.5.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.5.13-1 (2023-11-29) 
x86_64 GNU/Linux

:~$ sudo dmesg | grep usb
[1.112832] pci :00:1d.0: quirk_usb_early_handoff+0x0/0x7d0 took 17128 
usecs
[4.770474] usbcore: registered new interface driver usbfs
[4.770517] usbcore: registered new interface driver hub
[4.770612] usbcore: registered new device driver usb
[5.028858] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, 
bcdDevice= 6.05
[5.028871] usb usb1: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[5.028880] usb usb1: Product: EHCI Host Controller
[5.028887] usb usb1: Manufacturer: Linux 6.5.0-5-amd64 ehci_hcd
[5.028893] usb usb1: SerialNumber: :00:1d.0
[5.047937] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002, 
bcdDevice= 6.05
[5.047951] usb usb2: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[5.047960] usb usb2: Product: xHCI Host Controller
[5.047967] usb usb2: Manufacturer: Linux 6.5.0-5-amd64 xhci-hcd
[5.047974] usb usb2: SerialNumber: :00:14.0
[5.102086] usb usb3: New USB device found, idVendor=1d6b, idProduct=0003, 
bcdDevice= 6.05
[5.102107] usb usb3: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[5.102116] usb usb3: Product: xHCI Host Controller
[5.102123] usb usb3: Manufacturer: Linux 6.5.0-5-amd64 xhci-hcd
[5.102131] usb usb3: SerialNumber: :00:14.0
[5.501707] usb 1-1: new high-speed USB device number 2 using ehci-pci
[5.657069] usb 1-1: New USB device found, idVendor=8087, idProduct=8000, 
bcdDevice= 0.04
[5.657087] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[6.196709] usb 1-1.5: new full-speed USB device number 3 using ehci-pci
[6.306732] usb 1-1.5: New USB device found, idVendor=8087, idProduct=0a2b, 
bcdDevice= 0.01
[6.306745] usb 1-1.5: New USB device strings: Mfr=0, Product=0, 
SerialNumber=0
[6.384712] usb 1-1.6: new full-speed USB device number 4 using ehci-pci
[6.495352] usb 1-1.6: New USB device found, idVendor=04f3, idProduct=034f, 
bcdDevice=11.11
[6.495365] usb 1-1.6: New USB device strings: Mfr=4, Product=14, 
SerialNumber=0
[6.495371] usb 1-1.6: Product: Touchscreen
[6.495375] usb 1-1.6: Manufacturer: ELAN
[6.576712] usb 1-1.7: new high-speed USB device number 5 using ehci-pci
[6.685553] usb 1-1.7: New USB device found, idVendor=0bda, idProduct=0129, 
bcdDevice=39.60
[6.685565] usb 1-1.7: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[6.685571] usb 1-1.7: Product: USB2.0-CRW
[6.685575] usb 1-1.7: Manufacturer: Generic
[6.685579] usb 1-1.7: SerialNumber: 2010020139600
[6.772707] usb 1-1.8: new high-speed USB device number 6 using ehci-pci
[6.902694] usbcore: registered new interface driver usbhid
[6.902708] usbhid: USB HID core driver
[   13.423833] usb 1-1.8: New USB device found, idVendor=0bda, idProduct=5754, 
bcdDevice=41.21
[   13.423851] usb 1-1.8: New USB device strings: Mfr=3, Product=1, 
SerialNumber=2
[   13.423862] usb 1-1.8: Product: Integrated_Webcam_HD
[   13.423870] usb 1-1.8: Manufacturer: CN06307G7248745OB3VRA00
[   13.423876] usb 1-1.8: SerialNumber: 200901010001
[   13.426904] usbcore: registered new interface driver rtsx_usb
[   57.988717] usb 2-2: new low-speed USB device number 2 using xhci_hcd
[   58.139680] usb 2-2: New USB device found, idVendor=275d, idProduct=0ba6, 
bcdDevice= 1.00
[   58.139693] usb 2-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[   58.139699] usb 2-2: Product: USB OPTICAL MOUSE
[   58.143196] input: USB OPTICAL MOUSE  as 
/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.0/0003:275D:0BA6.0002/input/input11
[   58.143433] hid-generic 0003:275D:0BA6.0002: input,hidraw1: USB HID v1.11 
Mouse [USB OPTICAL MOUSE ] on usb-:00:14.0-2/input0
[   58.744716] usb 1-1.3: new low-speed USB device number 7 using ehci-pci
[   58.858361] usb 1-1.3: New USB device found, idVendor=1a2c, idProduct=0e24, 
bcdDevice= 1.10
[   58.858374] usb 1-1.3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[   58.858380] usb 1-1.3: Product: USB Keyboard
[   58.858384] usb 1-1.3

Re: xfce screen detachment

[tomas]

On Sat, Jan 13, 2024 at 06:31:38PM +0700, Max Nikulin wrote:
> On 13/01/2024 14:16, to...@tuxteam.de wrote:
> > 
> > Some days I'm glad I stuck to the most primitive window manager
> > I could get.
> 
> XFree86 (X11 server) had a similar feature a quarter of century ago and it
> worked in any window managers. If an application had overloaded GUI that did
> not fit to supported monitor resolution (perhaps 800x600) then it was
> possible to set larger virtual screen. When mouse cursor touched border of
> physical screen, virtual one scrolled reveling its hidden part.

Good old times -- I remember :-)

Was useful when you had 640x400 pixels...

[these days the window manager does that for me, but we have an agreement
on when and how]

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: xfce screen detachment

[Max Nikulin]

On 13/01/2024 14:16, to...@tuxteam.de wrote:


Some days I'm glad I stuck to the most primitive window manager
I could get.


XFree86 (X11 server) had a similar feature a quarter of century ago and 
it worked in any window managers. If an application had overloaded GUI 
that did not fit to supported monitor resolution (perhaps 800x600) then 
it was possible to set larger virtual screen. When mouse cursor touched 
border of physical screen, virtual one scrolled reveling its hidden part.

Re: xfce screen detachment

[tomas]

On Fri, Jan 12, 2024 at 02:41:47PM -0500, Cindy Sue Causey wrote:
> On 1/8/24, mick.crane  wrote:

[...]

> > I get this effect if pressing Alt and moving the mouse wheel.
> 
> 
> Me, too, in LXQt. It's HARD finding the fix until you can finally
> remember it. It's easy to hit a wall of misses when searching the
> Internet.

Ouch. GUI distopia.

Some days I'm glad I stuck to the most primitive window manager
I could get.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: xfce screen detachment

[Russell L. Harris]

On Fri, Jan 12, 2024 at 02:41:47PM -0500, Cindy Sue Causey wrote:

On 1/8/24, mick.crane  wrote:

On 2024-01-07 04:00, Russell L. Harris wrote:

system:  amd64 desktop, debian 12, xfce, NEC MultiSync EA192M monitor

I don't know precisely how to describe the problem, other than
"detachment".  About every week or so, when using the rodent, the
entire screen -- borders and all -- moves with respect to the monitor
screen as I move the mouse.

The only recovery method I have discovered is to reboot.

My hands and finders no longer are working well, so I likely clicked
on something or pressed a key to cause the problem.


I get this effect if pressing Alt and moving the mouse wheel.



Me, too, in LXQt. It's HARD finding the fix until you can finally
remember it. It's easy to hit a wall of misses when searching the
Internet.

As Mick says, hold down the ALT key and scroll the mouse rodent's
wheel back and forth. I just blew up my desktop background to where it
was basically one rendition of the small gif file that's normally
tiled.

It seems to be for commendable visual accessibility purposes, but it's
sure a grouch maker until you figure out its activation/deactivation
secret, lol.

Cindy :)
--
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *


Cindy, Thanks for taking the trouble to post the confirmation.  RLH
--
He turneth rivers into a wilderness, and the watersprings into dry
ground; a fruitful land into barrenness, for the wickedness of them
that dwell therein. - Psalm 107:33-34

Re: xfce screen detachment

[Cindy Sue Causey]

On 1/8/24, mick.crane  wrote:
> On 2024-01-07 04:00, Russell L. Harris wrote:
>> system:  amd64 desktop, debian 12, xfce, NEC MultiSync EA192M monitor
>>
>> I don't know precisely how to describe the problem, other than
>> "detachment".  About every week or so, when using the rodent, the
>> entire screen -- borders and all -- moves with respect to the monitor
>> screen as I move the mouse.
>>
>> The only recovery method I have discovered is to reboot.
>>
>> My hands and finders no longer are working well, so I likely clicked
>> on something or pressed a key to cause the problem.
>
> I get this effect if pressing Alt and moving the mouse wheel.


Me, too, in LXQt. It's HARD finding the fix until you can finally
remember it. It's easy to hit a wall of misses when searching the
Internet.

As Mick says, hold down the ALT key and scroll the mouse rodent's
wheel back and forth. I just blew up my desktop background to where it
was basically one rendition of the small gif file that's normally
tiled.

It seems to be for commendable visual accessibility purposes, but it's
sure a grouch maker until you figure out its activation/deactivation
secret, lol.

Cindy :)
-- 
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *

Re: xfce screen detachment

[mick.crane]

On 2024-01-07 04:00, Russell L. Harris wrote:

system:  amd64 desktop, debian 12, xfce, NEC MultiSync EA192M monitor

I don't know precisely how to describe the problem, other than
"detachment".  About every week or so, when using the rodent, the
entire screen -- borders and all -- moves with respect to the monitor
screen as I move the mouse.

The only recovery method I have discovered is to reboot.

My hands and finders no longer are working well, so I likely clicked
on something or pressed a key to cause the problem.

RLH


I get this effect if pressing Alt and moving the mouse wheel.
mick

Re: xfce screen detachment

[Russell L. Harris]

On Sun, Jan 07, 2024 at 09:32:55PM -0800, Mike Kupfer wrote:

Dan Ritter wrote:


Russell L. Harris wrote:
> system:  amd64 desktop, debian 12, xfce, NEC MultiSync EA192M monitor

[...]

That sounds something like having an X11 screen larger than the
monitor it is on, and X panning around that. Typically, though,
panning requires the mouse to hit the border of the monitor.

If that's what is happening, try right clicking-on the desktop
to get the application menu, and run Settings => Desktop; then
reset the resolution to what your monitor actually supports.


FWIW, I've noticed that Xfce eventually gets confused about the settings
for my display.  I don't know what triggers it, but I'll suddenly notice
that the display has gone from 1920x1200 to 1920x1080.  Resetting it
works (under Display, not Desktop).  I don't see the problem with MATE,
KDE, Cinnamon, or i3.

This is on Debian 11, amd64 desktop (radeon 3000 video), Acer 23"
monitor.



I opened the display settings, but whatever I did did not correct the
problem.  The next time it happens I try display settings again and
pay closer attention.  Thanks.  RLH

Re: xfce screen detachment

[Mike Kupfer]

Dan Ritter wrote:

> Russell L. Harris wrote: 
> > system:  amd64 desktop, debian 12, xfce, NEC MultiSync EA192M monitor
[...]
> That sounds something like having an X11 screen larger than the
> monitor it is on, and X panning around that. Typically, though,
> panning requires the mouse to hit the border of the monitor.
> 
> If that's what is happening, try right clicking-on the desktop
> to get the application menu, and run Settings => Desktop; then
> reset the resolution to what your monitor actually supports.

FWIW, I've noticed that Xfce eventually gets confused about the settings
for my display.  I don't know what triggers it, but I'll suddenly notice
that the display has gone from 1920x1200 to 1920x1080.  Resetting it
works (under Display, not Desktop).  I don't see the problem with MATE,
KDE, Cinnamon, or i3.

This is on Debian 11, amd64 desktop (radeon 3000 video), Acer 23"
monitor.

regards,
mike

Re: xfce screen detachment

[Dan Ritter]

Russell L. Harris wrote: 
> system:  amd64 desktop, debian 12, xfce, NEC MultiSync EA192M monitor
> 
> I don't know precisely how to describe the problem, other than
> "detachment".  About every week or so, when using the rodent, the
> entire screen -- borders and all -- moves with respect to the monitor
> screen as I move the mouse.
> 
> The only recovery method I have discovered is to reboot.
> 
> My hands and finders no longer are working well, so I likely clicked
> on something or pressed a key to cause the problem.

That sounds something like having an X11 screen larger than the
monitor it is on, and X panning around that. Typically, though,
panning requires the mouse to hit the border of the monitor.

If that's what is happening, try right clicking-on the desktop
to get the application menu, and run Settings => Desktop; then
reset the resolution to what your monitor actually supports.

You might also check if some key is being held down on your
keyboard, or if your mouse buttons are misfiring.

-dsr-

xfce screen detachment

[Russell L. Harris]

system:  amd64 desktop, debian 12, xfce, NEC MultiSync EA192M monitor

I don't know precisely how to describe the problem, other than
"detachment".  About every week or so, when using the rodent, the
entire screen -- borders and all -- moves with respect to the monitor
screen as I move the mouse.   


The only recovery method I have discovered is to reboot.

My hands and finders no longer are working well, so I likely clicked
on something or pressed a key to cause the problem.

RLH

Re: screen lock shuts down attached HDDs, they don't start up again

[Zenaan Harkness]

On 11/22/23, Zenaan Harkness  wrote:
> On 11/21/23, Michael Kjörling <2695bd53d...@ewoof.net> wrote:
>> On 21 Nov 2023 14:48 +1100, from zen...@gmail.com (Zenaan Harkness):
>>> The desktop displays, but my external HDDs have been put to sleep, and
>>> they do not wake up.
>>>
>>> One of them is zfs. The zfs mounts list shows, but any attempt to
>>> view/ls a zfs mount, just hangs permanently until a reboot.
>>>
>>> The other drive is an ext4 filesystem, and it has been completely
>>> un-mounted and the HDD spun down, and it does not spin up again -
>>> until a reboot.
>>
>> This doesn't sound right.
>>
>> Can you run hdparm -C on the affected devices at the time? What is the
>> result of that?
>
> So it seems I can test this quickly with a manual suspend, then do the
> various checks... it seems that the issue here is the
> auto-sleep/suspend.
>
> For starters, prior to suspend, I've removed the zfs drive, and just
> left the ext4 drive in the USB caddy (it holds up to 2 drives).
>
> Prior to suspend, I get, for the 2.5 inch hdd when it has not been
> accessed for a while and I can feel it is not spinning:
>
> # hdparm -C /dev/sda
> /dev/sda:
>  drive state is:  standby
>
> then, I ls'ed a dir in that drive that had not previously been
> accessed, and could feel it spin up and then give me the output, and
> then I ran hdparm again and interestingly, checking a few times on the
> now spun up drive, I get identical results as with the drive in the
> spun down state:
>
> # hdparm -C /dev/sda
> /dev/sda:
>  drive state is:  standby
>
> 
> Now, after suspend (and wait for hdd to spin down, and wait for
> monitors to blank, and wait another 10s) and finally wake the computer
> up (which is really too slow - 20 or 30 seconds or so, so something
> odd or challenging seems to be happening inside the kernel somewhere):
>
> # ll /dev/sd*
> ls: cannot access '/dev/sd*': No such file or directory
>
> # hdparm -C /dev/sda
> /dev/sda: No such file or directory
>
>
>> Do the drives spin back up if you use hdparm -z?
>
> Prior to suspend and wake, I get this:
>
> # hdparm -z /dev/sda
> /dev/sda:
>  re-reading partition table
>  BLKRRPART failed: Device or resource busy
>
> And again, after suspend and wake there is no more /dev/sda, or any
> /dev/sd*, so I cannot run hdparm on any such device.
>
>
>> What is the exact kernel version you are running? Please provide both
>> the package name and exact package version, and the full output from
>> uname -a.
>
> # uname -a
> Linux zen-L7 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1
> (2023-09-29) x86_64 GNU/Linux
>
> The kernel package is exactly
> linux-image-6.1.0-13-amd64
>
>
>> Assuming that those drives are connected over USB, do they show up in
>> lsusb output while inaccessible?
>
> Prior to suspend and wake, lsusb shows me my hubs, dock, eth adaptors,
> trackball, and possibly the following is the HDD dock ? dunno:
>
> Bus 006 Device 015: ID 152d:0565 JMicron Technology Corp. / JMicron
> USA Technology Corp. JMS56x Series
>
> ... and sure enough after suspend and wake, Bus 006 Device 015 is
> gone, no longer exists, so it somehow has not woken up - but I CAN
> still see the blue light on the hdd caddy, but the hdd remains in a
> spun down/ sleep state, and no /dev/sd* device.


I apologize, the above para was inserted after I did the suspend and
wake cycle, and the following paras were done before that. I apologize
for the confusion, so just be aware the following paras are part of
the "Prior to suspend..." para above.

> I do get these though (alias ll='ls -l'):
>
> # find /dev/disk/|grep usb
> /dev/disk/by-id/usb-WDC_WD20_SPZX-22UA7T0_RANDOM__3F4917AD758C-0:0
> /dev/disk/by-path/pci-:3a:00.0-usb-0:2.3.1:1.0-scsi-0:0:0:0
>
> # ll /dev/disk/by-path/pci-:3a:00.0-usb-0:2.3.1:1.0-scsi-0:0:0:0
> 0 lrwxrwxrwx 1 root root 9 20231122 10:33.10
> /dev/disk/by-path/pci-:3a:00.0-usb-0:2.3.1:1.0-scsi-0:0:0:0 ->
> ../../sda
>
> # ll /dev/sd*
> 0 brw-rw 1 root disk 8, 0 20231122 10:33.10 /dev/sda
>
> ... interestingly, it seems when I formatted this drive with ext4, I
> formatted ext4 on the whole disk (/dev/sda) without using partitions,
> and so it's just /dev/sda and not /dev/sda1, which has the ext4
> filesystem.
>
>
>> Is there anything relevant in dmesg output?
>
> This looks quite suspicious (some error lines, not all of dmesg output):
>
> [42635.638996] usb 6-2.3.1: device not accepting address 15, error -62
> [42668.986050] usb 6-2.3.1: USB disconnect, device number 15
> [42668.986406] device offline error, dev sda, sector 0 op 0x1:(WRITE)
> flags 0x800 phys_seg 0 prio class 2
> [42668.988647] hub 6-2.3.2:1.0: hub_ext_port_status failed (err = -71)
> [42668.990867] hub 6-2.3.2.3:1.0: hub_ext_port_status failed (err = -71)
> [42668.990888] hub 6-2.3.2.1:1.0: hub_ext_port_status failed (err = -71)
> [42669.007554] usb 6-2.3.2.3.1: Failed to suspend device, error -71
> [42669.008775] hub 6-2.3.2:1.0: hub_ext_port_status failed (err = -71)
> 

Re: screen lock shuts down attached HDDs, they don't start up again

[Zenaan Harkness]

On 11/21/23, Michael Kjörling <2695bd53d...@ewoof.net> wrote:
> On 21 Nov 2023 14:48 +1100, from zen...@gmail.com (Zenaan Harkness):
>> The desktop displays, but my external HDDs have been put to sleep, and
>> they do not wake up.
>>
>> One of them is zfs. The zfs mounts list shows, but any attempt to
>> view/ls a zfs mount, just hangs permanently until a reboot.
>>
>> The other drive is an ext4 filesystem, and it has been completely
>> un-mounted and the HDD spun down, and it does not spin up again -
>> until a reboot.
>
> This doesn't sound right.
>
> Can you run hdparm -C on the affected devices at the time? What is the
> result of that?

So it seems I can test this quickly with a manual suspend, then do the
various checks... it seems that the issue here is the
auto-sleep/suspend.

For starters, prior to suspend, I've removed the zfs drive, and just
left the ext4 drive in the USB caddy (it holds up to 2 drives).

Prior to suspend, I get, for the 2.5 inch hdd when it has not been
accessed for a while and I can feel it is not spinning:

# hdparm -C /dev/sda
/dev/sda:
 drive state is:  standby

then, I ls'ed a dir in that drive that had not previously been
accessed, and could feel it spin up and then give me the output, and
then I ran hdparm again and interestingly, checking a few times on the
now spun up drive, I get identical results as with the drive in the
spun down state:

# hdparm -C /dev/sda
/dev/sda:
 drive state is:  standby


Now, after suspend (and wait for hdd to spin down, and wait for
monitors to blank, and wait another 10s) and finally wake the computer
up (which is really too slow - 20 or 30 seconds or so, so something
odd or challenging seems to be happening inside the kernel somewhere):

# ll /dev/sd*
ls: cannot access '/dev/sd*': No such file or directory

# hdparm -C /dev/sda
/dev/sda: No such file or directory


> Do the drives spin back up if you use hdparm -z?

Prior to suspend and wake, I get this:

# hdparm -z /dev/sda
/dev/sda:
 re-reading partition table
 BLKRRPART failed: Device or resource busy

And again, after suspend and wake there is no more /dev/sda, or any
/dev/sd*, so I cannot run hdparm on any such device.


> What is the exact kernel version you are running? Please provide both
> the package name and exact package version, and the full output from
> uname -a.

# uname -a
Linux zen-L7 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1
(2023-09-29) x86_64 GNU/Linux

The kernel package is exactly
linux-image-6.1.0-13-amd64


> Assuming that those drives are connected over USB, do they show up in
> lsusb output while inaccessible?

Prior to suspend and wake, lsusb shows me my hubs, dock, eth adaptors,
trackball, and possibly the following is the HDD dock ? dunno:

Bus 006 Device 015: ID 152d:0565 JMicron Technology Corp. / JMicron
USA Technology Corp. JMS56x Series

... and sure enough after suspend and wake, Bus 006 Device 015 is
gone, no longer exists, so it somehow has not woken up - but I CAN
still see the blue light on the hdd caddy, but the hdd remains in a
spun down/ sleep state, and no /dev/sd* device.

I do get these though (alias ll='ls -l'):

# find /dev/disk/|grep usb
/dev/disk/by-id/usb-WDC_WD20_SPZX-22UA7T0_RANDOM__3F4917AD758C-0:0
/dev/disk/by-path/pci-:3a:00.0-usb-0:2.3.1:1.0-scsi-0:0:0:0

# ll /dev/disk/by-path/pci-:3a:00.0-usb-0:2.3.1:1.0-scsi-0:0:0:0
0 lrwxrwxrwx 1 root root 9 20231122 10:33.10
/dev/disk/by-path/pci-:3a:00.0-usb-0:2.3.1:1.0-scsi-0:0:0:0 ->
../../sda

# ll /dev/sd*
0 brw-rw 1 root disk 8, 0 20231122 10:33.10 /dev/sda

... interestingly, it seems when I formatted this drive with ext4, I
formatted ext4 on the whole disk (/dev/sda) without using partitions,
and so it's just /dev/sda and not /dev/sda1, which has the ext4
filesystem.


> Is there anything relevant in dmesg output?

This looks quite suspicious (some error lines, not all of dmesg output):

[42635.638996] usb 6-2.3.1: device not accepting address 15, error -62
[42668.986050] usb 6-2.3.1: USB disconnect, device number 15
[42668.986406] device offline error, dev sda, sector 0 op 0x1:(WRITE)
flags 0x800 phys_seg 0 prio class 2
[42668.988647] hub 6-2.3.2:1.0: hub_ext_port_status failed (err = -71)
[42668.990867] hub 6-2.3.2.3:1.0: hub_ext_port_status failed (err = -71)
[42668.990888] hub 6-2.3.2.1:1.0: hub_ext_port_status failed (err = -71)
[42669.007554] usb 6-2.3.2.3.1: Failed to suspend device, error -71
[42669.008775] hub 6-2.3.2:1.0: hub_ext_port_status failed (err = -71)
42713.495809] xhci_hcd :3a:00.0: Timeout while waiting for setup
device command
[42713.703761] usb 6-2.3.1: device not accepting address 19, error -62
[42713.704792] usb 6-2.3-port1: unable to enumerate USB device
[42713.708332] usb 6-2.3.2: USB disconnect, device number 5
[42713.708343] usb 6-2.3.2.1: USB disconnect, device number 7


since "2.3.1" appears in the drive links above, and 6 could be "Bus
6". I'm not familiar with dmesg output though...

I also see the following, but 

Re: screen lock shuts down attached HDDs, they don't start up again

[Michael Kjörling]

On 21 Nov 2023 14:48 +1100, from zen...@gmail.com (Zenaan Harkness):
> The desktop displays, but my external HDDs have been put to sleep, and
> they do not wake up.
> 
> One of them is zfs. The zfs mounts list shows, but any attempt to
> view/ls a zfs mount, just hangs permanently until a reboot.
> 
> The other drive is an ext4 filesystem, and it has been completely
> un-mounted and the HDD spun down, and it does not spin up again -
> until a reboot.

This doesn't sound right.

Can you run hdparm -C on the affected devices at the time? What is the
result of that?

Do the drives spin back up if you use hdparm -z?

What is the exact kernel version you are running? Please provide both
the package name and exact package version, and the full output from
uname -a.

Assuming that those drives are connected over USB, do they show up in
lsusb output while inaccessible?

Is there anything relevant in dmesg output?

Are you booting the kernel with any command-line parameters? Please
provide the exact contents of /proc/cmdline.

A spun-down drive can take a brief time to spin back up (typically on
the order of a few seconds), but that SHOULD be handled automatically;
clearly something odd is going on in your case if it doesn't.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

screen lock shuts down attached HDDs, they don't start up again

[Zenaan Harkness]

Every time the screen lock kicks in, and I return to my debian gnome
desktop, I press Enter, wait for 20 seconds, press Enter again,
eventually the monitor wakes up and I enter the password.

The desktop displays, but my external HDDs have been put to sleep, and
they do not wake up.

One of them is zfs. The zfs mounts list shows, but any attempt to
view/ls a zfs mount, just hangs permanently until a reboot.

The other drive is an ext4 filesystem, and it has been completely
un-mounted and the HDD spun down, and it does not spin up again -
until a reboot.

This seems rather drastic, and unexpected. Surely others have
forgotten to dismount external drives, or taken too long to return to
the computer and had the screen lock kick in, and the external drives
"permanently" shut down?

Any ideas on how to stop this, without disabling the Gnome screen
lock? (I do want the screen to lock if I forget to lock it, or if I
manually lock it, if I'm away from my pc for a while)

Re: Bookworm boot stacks with black screen after NVIDIA driver installed.

[Juan R. de Silva]

On Wed, 16 Aug 2023 15:31:52 +0300, Махно wrote:

> Hello. Just stick with open source video driver nouveau.
This is what I'm doing right now. However it performes, as I already said, 
"good enough". Meaning there are some problems. It freezes the system from 
time to time. Well, for now I do not have any choice anyway.

Re: Bookworm boot stacks with black screen after NVIDIA driver installed.

[Махно]

Hello. Just stick with open source video driver nouveau.

2023-08-16, tr, 04:13 Alexander V. Makartsev  rašė:
>
> On 16.08.2023 04:06, Juan R.D. Silva wrote:
>
> Hi folks.
>
> Fresh Bookworm install on Dell M4800 Precision with i7-4810MQ CPU @ 2.80GHz 
> and NVIDIA Quadro K2100M graphic card. No problems install, the system works 
> with the default nouveau driver well enough.
>
> My video card is supported according to NVIDIA.
>
> Information on official Nvidia website suggests otherwise. Last driver 
> version that supports your VGA is 418 release. [1]
> Newer driver versions don't mention K2100M on "Supported Products" list.
>
> Debian nvidia-detect advised installation of nvidia-tesla-470-driver 
> available in repo. After installing it the system boot stacks somewhere in 
> the middle with a weird black screen. No access to TTYs, no cursor, no 
> reaction to keyboard. I tried to boot with "nomodeset" in GRUB with no result.
>
> Installation of drivers newer than 418 version wouldn't work. The only thing 
> they will do is blacklist "nouveau".
> Version 418 is available in Buster which is current "oldoldstable". [2]
> You can try to backport driver from "oldoldstable" to Bookworm. It might be 
> an impossible task due to possible incompatibilities with kernel 6.x
> There is also an option to install official driver package from Nvidia.
> Or you can install and use Buster.
>
>
> [1] https://www.nvidia.com/download/driverResults.aspx/153717/en-us/
> [2] https://wiki.debian.org/DebianOldOldStable
>
> --
> With kindest regards, Alexander.
>
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
> ⠈⠳⣄

Re: Bookworm boot stacks with black screen after NVIDIA driver installed.

[Alexander V. Makartsev]

On 16.08.2023 04:06, Juan R.D. Silva wrote:

Hi folks.

Fresh Bookworm install on Dell M4800 Precision with i7-4810MQ CPU @ 
2.80GHz and NVIDIA Quadro K2100M graphic card. No problems install, 
the system works with the default nouveau driver well enough.


My video card is supported according to NVIDIA. 
Information on official Nvidia website suggests otherwise. Last driver 
version that supports your VGA is 418 release. [1]

Newer driver versions don't mention K2100M on "Supported Products" list.

Debian nvidia-detect advised installation of nvidia-tesla-470-driver 
available in repo. After installing it the system boot stacks 
somewhere in the middle with a weird black screen. No access to TTYs, 
no cursor, no reaction to keyboard. I tried to boot with "nomodeset" 
in GRUB with no result.
Installation of drivers newer than 418 version wouldn't work. The only 
thing they will do is blacklist "nouveau".

Version 418 is available in Buster which is current "oldoldstable". [2]
You can try to backport driver from "oldoldstable" to Bookworm. It might 
be an impossible task due to possible incompatibilities with kernel 6.x

There is also an option to install official driver package from Nvidia.
Or you can install and use Buster.


[1] https://www.nvidia.com/download/driverResults.aspx/153717/en-us/
[2] https://wiki.debian.org/DebianOldOldStable

--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Bookworm boot stacks with black screen after NVIDIA driver installed.

[Juan R.D. Silva]

Hi folks.

Fresh Bookworm install on Dell M4800 Precision with i7-4810MQ CPU @ 
2.80GHz and NVIDIA Quadro K2100M graphic card. No problems install, the 
system works with the default nouveau driver well enough.


My video card is supported according to NVIDIA. Debian nvidia-detect 
advised installation of nvidia-tesla-470-driver available in repo. After 
installing it the system boot stacks somewhere in the middle with a 
weird black screen. No access to TTYs, no cursor, no reaction to 
keyboard. I tried to boot with "nomodeset" in GRUB with no result.


When rebooted in restore mode neither journal -b or journal -xe showed 
any problems. Nvidia module seems to be inserted and loaded. No other 
problems reported. The only way out is to execute 'apt purge "*nvidia*", 
and to reboot. The system then reverts to nouveau driver without any 
problems.


Anyone, please?

Thanks.

Re: [Debian 12 Issue] Black Screen after starting X11. Cant log in into Graphical Environments. Either DEs or WMs. AMD Radeon GPU problems

[Michel Verdier]

Le 18 juin 2023 Paul Gerdes a écrit :

> i get these messages:
> "grep: /var/log/Xorg.*: No such file or directory"
> "grep: /var/log/Xorg: No such file or directory"
>
> looks like there is no log file for X11

Did you also try to start X with startx from a tty ?

Can you provide
find /etc/ | grep xorg

And from your login user
grep EE ~/.local/share/xorg/Xorg.*
grep WW ~/.local/share/xorg/Xorg.*
cat ~/.bash_profile
cat ~/.xserverrc
cat ~/.xsession
cat ~/.xsession-errors

Re: [Debian 12 Issue] Black Screen after starting X11. Cant log in into Graphical Environments. Either DEs or WMs. AMD Radeon GPU problems

[Michel Verdier]

On 2023-06-17, Paul Gerdes wrote:

> Hi i have a problem with Debian 12 after Installation.
> Every time i try to log in to the Desktop Environment or WM my Screen goes
> black. The PC completely freezes and i cant switch to another TTY.

Did you check X logs ? With something like

grep EE /var/log/Xorg.*
grep WW /var/log/Xorg.*

[Debian 12 Issue] Black Screen after starting X11. Cant log in into Graphical Environments. Either DEs or WMs. AMD Radeon GPU problems

[Paul Gerdes]

Hi i have a problem with Debian 12 after Installation.
Every time i try to log in to the Desktop Environment or WM my Screen goes
black. The PC completely freezes and i cant switch to another TTY.

I reinstalled Debian 12 a few times via netinstall. Tried different Desktop
Environments and WMs. The Installation runs through without any issues.
Running Debian without graphical environment (Terminal only TTY) is running
fine. Installing packages via apt is also fine. As soon as i install a DE
or WM and restart the machine, the screen goes black (after showing the
boot screen). I cant log in to any Desktop.
I also tried booting the Live ISOs of Debian 12 Gnome and XFCE edition. And
Fedora Workstation 38 Live ISO. All of them have the same issues.

I found out that Linux runs fine when i took the AMD GPU out of the PC.
Running Linux only with internal Intel GPU. As soon as i put the AMD GPU
back in its starting to freeze / black out again.

Drivers and Firmware are installed following this wiki:
https://wiki.debian.org/AtiHowTo

The Systems Specs are:
Mainboard MSI CSM-Q87M-E43 (MS-7830)
Intel i5-4570
Graphics AMD Radeon R9 390 (Powercolor)
16 GB Ram Corsair DDR3-1333
SSD Gigabyte GP-GS 500GB

I had no issues with Windows 10 on this machine. 3D games and everything
runs fine.

Re: chromecast: no audio when casting screen

[javibarroso]

Hello, I'm trying to repply to an old thread, not sure if it will work 
(I'm using the link from 
https://lists.debian.org/debian-user/2021/02/msg00394.html openned with 
thunderbird)


*** Old thread ***
I have just find a posible solution

https://www.linuxuprising.com/2020/04/how-to-cast-your-gnome-shell-desktop-to.html?m=1

I will test it in unstable

Regards

El jue., 17 dic. 2020 10:19, Andrea Borgia  escribió:


   Il giorno gio 17 dic 2020 alle ore 07:12 Javier Barroso
ha scritto:


   It is a known issue , see

   https://support.google.com/chromecast/thread/27045993?hl=en


   Great find, thanks for the quick response too :)

*** Current repply ***
Now it is working without any workaround

Regards

Re: how to change boot screen image?

[b w]

/etc/grub.d/05_debian_theme  6059/6260
  96%

# First check whether the user has specified a background image explicitly.
# If so, try to use it. Don't try the other possibilities in that case
# (#608263).
if [ -n "${GRUB_BACKGROUND+x}" ]; then
set_background_image "${GRUB_BACKGROUND}" || set_default_theme
exit 0
fi

# Next search for pictures the user put into /boot/grub/ and use the first
one.
for background in *.jpg *.JPG *.jpeg *.JPEG *.png *.PNG *.tga *.TGA; do
if set_background_image "${background}"; then
exit 0
fi
done

# Next try to use the background image and colors specified by desktop-base.
if set_background_image "${WALLPAPER}" "${COLOR_NORMAL}"
"${COLOR_HIGHLIGHT}"; then
exit 0
fi

# If we haven't found a background image yet, use the default from
desktop-base.

Re: how to change boot screen image?

[hlyg]

On 6/9/23 15:40, DdB wrote:



Thank DdB! i have some success

/usr/share/desktop-base/homeworld-theme/grub/

boot screen can be changed by replacing file in location above

i haven't been able to change login background



Very strange: if i use my favorite search engine, i find dozens of
places, describing a solution. And especially nowadays, where AI
specializes on giving useful hints and explanations to remedy computer
configuration problems, i am wondering as to why you keep asking here?

I have neither lxde nor lightdm, so cannot even verify those solutions,
but you should ... beginning with perhaps:
https://www.marksayson.com/blog/lxde-customizing-the-log-in-background/

.


if you insist on doing research including google and reading manual 
before posting to list,  i'm afraid list traffic could decrease dramatically


after all linux/debian is mature product, problem is usually with user, 
not with linux


ps: some threads are marked OT

Re: how to change boot screen image?

[DdB]

Am 09.06.2023 um 09:05 schrieb hlyg:
> 
> On 6/9/23 09:01, DdB wrote:
>>
>> STFW: https://www.youtube.com/watch?v=xAi2UfUkp_A
>>   +
>> https://unix.stackexchange.com/questions/349234/how-to-show-kernel-boot-messages-by-modifying-grub-config-files
>>
>>
>> .
> 
> Thank DdB! i have some success
> 
> /usr/share/desktop-base/homeworld-theme/grub/
> 
> boot screen can be changed by replacing file in location above
> 
> i haven't been able to change login background
> 
> 
Very strange: if i use my favorite search engine, i find dozens of
places, describing a solution. And especially nowadays, where AI
specializes on giving useful hints and explanations to remedy computer
configuration problems, i am wondering as to why you keep asking here?

I have neither lxde nor lightdm, so cannot even verify those solutions,
but you should ... beginning with perhaps:
https://www.marksayson.com/blog/lxde-customizing-the-log-in-background/

Re: how to change boot screen image?

[hlyg]

On 6/9/23 09:01, DdB wrote:


STFW: https://www.youtube.com/watch?v=xAi2UfUkp_A
  +
https://unix.stackexchange.com/questions/349234/how-to-show-kernel-boot-messages-by-modifying-grub-config-files

.


Thank DdB! i have some success

/usr/share/desktop-base/homeworld-theme/grub/

boot screen can be changed by replacing file in location above

i haven't been able to change login background

Re: how to change boot screen image?

[DdB]

Am 09.06.2023 um 01:45 schrieb hlyg:
> i've installed deb11 for i386 from live lxde CD
> 
> i want to change boot screen image
> 
> i browse /boot/grub, can't get clue
> 
> lxde has many menus to change appearance, but i can't find menu to
> change boot screen
> 
> btw is it possible to show kernel msg during boot?
> 
> 
STFW: https://www.youtube.com/watch?v=xAi2UfUkp_A
 +
https://unix.stackexchange.com/questions/349234/how-to-show-kernel-boot-messages-by-modifying-grub-config-files

how to change boot screen image?

[hlyg]

i've installed deb11 for i386 from live lxde CD

i want to change boot screen image

i browse /boot/grub, can't get clue

lxde has many menus to change appearance, but i can't find menu to 
change boot screen


btw is it possible to show kernel msg during boot?

Screen locker

[Nicolas George]

Hi.

I need a screen lock mechanism that does not let another user open a new
session (= if you lock to go to the bathroom, you get your place back),
but after a configurable amount of time (= if you lock and go to the
movies, you might not get your place back) has a dialog “this computer
is locked since…” and a button “force logout” (= your processes will not
waste resources until the next reboot).

Is there something like that available in Debian? Or not in Debian?

(We are using lightdm, but since we do not want to let extra sessions,
the solution does not need to cooperate with the display manager, so
that information should not be relevant. It is not an issue if users can
ctrl-alt-F2 to another VT and startx.)

Oh, I forgot: it needs to work with passwd and shadow from NIS, because
it's still the 20th century around here.

Regards,

-- 
  Nicolas George

Re: Virtual machine affects client screen resolution

[Roy J. Tellason, Sr.]

On Friday 24 February 2023 10:03:31 pm Max Nikulin wrote:
> On 25/02/2023 00:55, Roy J. Tellason, Sr. wrote:
> > On Wednesday 22 February 2023 09:24:17 pm Max Nikulin wrote:
> >> On 19/02/2023 01:01, Roy J. Tellason, Sr. wrote:
> >>> So this got me curious,  and I tried it out.  In the terminal that's
> >>> running inside of the virtualbox instance where I'm doing emails,  it
> >>> comes back with:
> >>>
> >>> :0
> >>
> >> Have you tried to emulate multiple monitors in virtualbox?
> > 
> > I'm not sure what I need to do with the computer to make this happen.
> 
> VirtualBox can emulate multiple monitors, they may be represented as 
> several windows on the same physical device. It is convenient to test 
> behavior of applications in the configuration with multiple monitors. 
> There is an option in VM configuration UI.

I don't recall seeing that,  I'll have another look...
 
> >>> But in a terminal which is running on the host Debian system,  it comes 
> >>> back with:
> >>>
> >>> :0.0
> >>>
> >>> I wonder why the difference?
> >>
> >> My guess is that it may depend on graphics adapter and its driver.
> > 
> > It's an older machine with a VGA output being used.  I assume that I'll
> > need to get some kind of a card with an HDMI output and a cable to make
> > that happen.  No idea what the driver is,  probably nothing special.
> 
> It does not matter if it is special or not. My guess (that may be wrong) 
> that even noveau vs. nvidia may behave differently. I have never gone 
> deeper, since I do not remember any problem with setting DISPLAY=:0 when 
> it was necessary. Driver in use should appear in Xorg.0.log, e.g.
> 
> (II) modeset(0): [DRI2]   DRI driver: i965

Only thing I'm finding that resembles that is these lines:

[ 13041.620] (II) modeset(0): [DRI2]   DRI driver: i965
[ 13041.620] (II) modeset(0): [DRI2]   VDPAU driver: i965
 
> >> I have heard that a display may have several screens (it is not the same 
> >> as multiple monitors that show
> >> different regions of the same display and screen). I have never tried such 
> >> configuration.
> > 
> > Are you referring to multiple desktops?  I have that going,  for sure.
> 
> My impression is that multiple screens of a display is not the same as 
> virtual desktops (and not the same as multiple monitors). I am not 
> familiar with X11 protocol so closely. Frankly speaking, I has a hope 
> that somebody will post a proper link. My curiosity is not strong enough 
> yet to filter search engine results myself.


-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

Re: Virtual machine affects client screen resolution

[Max Nikulin]

On 25/02/2023 00:55, Roy J. Tellason, Sr. wrote:

On Wednesday 22 February 2023 09:24:17 pm Max Nikulin wrote:

On 19/02/2023 01:01, Roy J. Tellason, Sr. wrote:

So this got me curious,  and I tried it out.  In the terminal that's
running inside of the virtualbox instance where I'm doing emails,  it
comes back with:

:0


Have you tried to emulate multiple monitors in virtualbox?


I'm not sure what I need to do with the computer to make this happen.


VirtualBox can emulate multiple monitors, they may be represented as 
several windows on the same physical device. It is convenient to test 
behavior of applications in the configuration with multiple monitors. 
There is an option in VM configuration UI.



But in a terminal which is running on the host Debian system,  it comes back 
with:

:0.0

I wonder why the difference?


My guess is that it may depend on graphics adapter and its driver.


It's an older machine with a VGA output being used.  I assume that I'll
need to get some kind of a card with an HDMI output and a cable to make
that happen.  No idea what the driver is,  probably nothing special.


It does not matter if it is special or not. My guess (that may be wrong) 
that even noveau vs. nvidia may behave differently. I have never gone 
deeper, since I do not remember any problem with setting DISPLAY=:0 when 
it was necessary. Driver in use should appear in Xorg.0.log, e.g.


(II) modeset(0): [DRI2]   DRI driver: i965


I have heard that a display may have several screens (it is not the same as 
multiple monitors that show
different regions of the same display and screen). I have never tried such 
configuration.


Are you referring to multiple desktops?  I have that going,  for sure.


My impression is that multiple screens of a display is not the same as 
virtual desktops (and not the same as multiple monitors). I am not 
familiar with X11 protocol so closely. Frankly speaking, I has a hope 
that somebody will post a proper link. My curiosity is not strong enough 
yet to filter search engine results myself.

Re: Virtual machine affects client screen resolution

[Roy J. Tellason, Sr.]

On Wednesday 22 February 2023 09:24:17 pm Max Nikulin wrote:
> 
> On 19/02/2023 01:01, Roy J. Tellason, Sr. wrote:
> > On Saturday 18 February 2023 12:17:20 am Max Nikulin wrote:
> >> echo "$DISPLAY"
> > 
> > So this got me curious,  and I tried it out.  In the terminal that's
> > running inside of the virtualbox instance where I'm doing emails,  it
> > comes back with:
> > 
> > :0
> 
> Have you tried to emulate multiple monitors in virtualbox?

Not yet.  I would like to go to multiple monitors at some point,  particularly 
once I get going with some of the CAD stuff I have installed that I really 
haven't done anything much with yet.  I'm not sure what I need to do with the 
computer to make this happen.
 
> > But in a terminal which is running on the host Debian system,  it comes 
> > back with:
> > 
> > :0.0
> > 
> > I wonder why the difference?
> 
> My guess is that it may depend on graphics adapter and its driver. 

It's an older machine with a VGA output being used.  I assume that I'll need to 
get some kind of a card with an HDMI output and a cable to make that happen.  
No idea what the driver is,  probably nothing special.

> I have heard that a display may have several screens (it is not the same as 
> multiple monitors that show
> different regions of the same display and screen). I have never tried such 
> configuration.

Are you referring to multiple desktops?  I have that going,  for sure.


-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

Re: Virtual machine affects client screen resolution

[Max Nikulin]

On 19/02/2023 01:01, Roy J. Tellason, Sr. wrote:

On Saturday 18 February 2023 12:17:20 am Max Nikulin wrote:

echo "$DISPLAY"


So this got me curious,  and I tried it out.  In the terminal that's
running inside of the virtualbox instance where I'm doing emails,  it
comes back with:

:0


Have you tried to emulate multiple monitors in virtualbox?


But in a terminal which is running on the host Debian system,  it comes back 
with:

:0.0

I wonder why the difference?


My guess is that it may depend on graphics adapter and its driver. I 
have heard that a display may have several screens (it is not the same 
as multiple monitors that show different regions of the same display and 
screen). I have never tried such configuration. I am unsure which 
approach is used in nvidia's xinerama.

Re: Virtual machine affects client screen resolution

[Albert S.]

My thanks to David Wright and Max Nikulin.

That was a good wake-up call. Most of my VMs are safe, but it was 
interesting to learn what was really going on.


ForwardX11 was enabled for the ssh session. Initially I imagined 
vncviewer (to the KVM host though ssh) was the one causing the problem, 
but now it is clear that the ssh session to the VM was responsible for it.


This was the result of checking open tcp ports on the VM:
$ netstat -nlt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address State
...
tcp0  0 127.0.0.53:53   0.0.0.0:*   LISTEN
tcp0  0 127.0.0.1:6010  0.0.0.0:*   LISTEN

$ echo $DISPLAY
localhost:10.0

It was also a good opportunity to learn about XPRA and test it.

Albert


On 2/17/23 22:15, David Wright wrote:

On Fri 17 Feb 2023 at 20:57:38 (-0500), Albert S. wrote:

Running “xrandr --size 800x600” on a virtual machine affected both
monitors on my workstation. That was completely unexpected and I am
wondering how to explain that.

Below you will find the detailed description.


[ … ]


But my real concern is how a xrandr command issued on a VM which is
running on another machine could affect the video of the client
machine used to access that VM.

I would appreciate an explanation for that.


The clue is in your use of the word "client". In fact, the "video of
the machine used to access that VM" is the X /server/. The
applications that you control on this machine, and others that you
connect to, which you thought were servers, are in fact the clients.

So, for example, I'm sitting at my All-in-One, running an X server as
usual. In a room down the hall, I have a laptop that's booted up, but
hasn't been used yet. It's sitting at a VC prompt waiting for someone
to log in. There's no X server running on it.

I've connected to the laptop with ssh from an xterm here on my A-i-O,
and typed into the /laptop/:

$ xrandr --output eDP --rotate right

and immediately, my screen blanks, comes back a second later, and
everything is sideways. When I type:

$ xrandr --output eDP --rotate normal

then normality is restored.

So I ran xrandr on the laptop, but xrandr is not concerned with that
machine, but only with the X /server/, running on my A-i-O.

https://en.wikipedia.org/wiki/X_Window_System

Cheers,
David.

Re: Virtual machine affects client screen resolution

[Roy J. Tellason, Sr.]

On Saturday 18 February 2023 12:17:20 am Max Nikulin wrote:
> echo "$DISPLAY"

So this got me curious,  and I tried it out.  In the terminal that's running 
inside of the virtualbox instance where I'm doing emails,  it comes back with:

:0

But in a terminal which is running on the host Debian system,  it comes back 
with:

:0.0

I wonder why the difference?

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

Re: Virtual machine affects client screen resolution

[Max Nikulin]

On 18/02/2023 08:57, Albert S. wrote:


If you think I issued the xrandr command on the wrong machine, that was 
not the case: history makes it clear.


Behavior depends on the DISPLAY environment value at the moment when 
xrandr was executed. Likely it was pointed not to vnc Xserver, but to 
the socket forwarded to your workstation by ssh. Try


echo "$DISPLAY"

In a local shell, in a ssh session, and from vncviewer.

Re: Virtual machine affects client screen resolution

[David Wright]

On Fri 17 Feb 2023 at 20:57:38 (-0500), Albert S. wrote:
> Running “xrandr --size 800x600” on a virtual machine affected both
> monitors on my workstation. That was completely unexpected and I am
> wondering how to explain that.
> 
> Below you will find the detailed description.

[ … ]

> But my real concern is how a xrandr command issued on a VM which is
> running on another machine could affect the video of the client
> machine used to access that VM.
> 
> I would appreciate an explanation for that.

The clue is in your use of the word "client". In fact, the "video of
the machine used to access that VM" is the X /server/. The
applications that you control on this machine, and others that you
connect to, which you thought were servers, are in fact the clients.

So, for example, I'm sitting at my All-in-One, running an X server as
usual. In a room down the hall, I have a laptop that's booted up, but
hasn't been used yet. It's sitting at a VC prompt waiting for someone
to log in. There's no X server running on it.

I've connected to the laptop with ssh from an xterm here on my A-i-O,
and typed into the /laptop/:

$ xrandr --output eDP --rotate right

and immediately, my screen blanks, comes back a second later, and
everything is sideways. When I type:

$ xrandr --output eDP --rotate normal

then normality is restored.

So I ran xrandr on the laptop, but xrandr is not concerned with that
machine, but only with the X /server/, running on my A-i-O.

https://en.wikipedia.org/wiki/X_Window_System

Cheers,
David.

Virtual machine affects client screen resolution

[Albert S.]

Running “xrandr --size 800x600” on a virtual machine affected both 
monitors on my workstation. That was completely unexpected and I am 
wondering how to explain that.


Below you will find the detailed description.

I run KVM on a Debian 11 server, which has no monitor or keyboard 
attached to it. One of the VMs running on that server is a Ubuntu 
desktop 22.04 LTS (I needed the desktop version due to the application I 
was running there). From another machine (a workstation running Debian 
11, xfce) with two monitors I access the Ubuntu VM when I need to. I use 
ssh to the server to establish a ssh tunnel, and then access the Ubuntu 
machine with the command “/usr/lib/ssvnc/vncviewer localhost:5906 &”.


A couple of weeks ago I decided to increase the Ubuntu VM resolution to 
1600x1200 to make my work easier, and that initially worked. However, 
today, after a reboot of the Debian server and all VMs, I noticed that 
the Ubuntu screen (through VNC) would still have the resolution of 
1600x1200 when displayed on my workstation, but it would display as 
black on the top and gray on the bottom, without any image. The VM 
console was dead. However, I could still access the VM through ssh. So, 
I started trying different commands to fix the problem. One of the 
commands I issued on the VM (through ssh) was “xrandr –size 800x600”.


When I issued the xrandr command, one display on my workstation turned 
off, and the other one went to 800x600 resolution. That was completely 
unexpected. I am asking myself how can a command issued on a VM which is 
running on a different machine affect the screen resolution of the 
workstation used to access that VM. Just to be clear, I was accessing 
that VM both through ssh and through vncviewer (still back and gray 
screen image) when that happened.


If you think I issued the xrandr command on the wrong machine, that was 
not the case: history makes it clear.


Just to be complete, the solution to the video problem was to make a 
change on the KVM xml file, from video type=vga to type=virtio.


But my real concern is how a xrandr command issued on a VM which is 
running on another machine could affect the video of the client machine 
used to access that VM.


I would appreciate an explanation for that.

Thanks,

Albert

Re: loss of screen resolution, part 2

[gene heskett]

On 12/21/22 03:37, to...@tuxteam.de wrote:

On Tue, Dec 20, 2022 at 05:26:06PM +, Kleene, Steven (kleenesj) wrote:

[...]


On Tuesday, December 20, 2022 10:36 AM, Max Nikulin wrote:

get-edid | parse-edid
edid-decode /sys/class/drm/card0-HDMI-A-1/edid

Thanks.  get-edid doesn't find any EDIDs, and there are no edid files under
/sys/devices.


Could it just be that the microcontroller (in the display)
responsible for providing the EDID is dead?

Cheers


That, Tomas,  depending on how old the purchase receipt is, should be 
grounds for returning it for credit against one that works.


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: loss of screen resolution, part 2

[gene heskett]

On 12/20/22 12:27, Kleene, Steven (kleenesj) wrote:

On Monday, December 19, 2022 9:12 PM, I wrote:

Today I have my new desktop and did a clean install of Bullseye.  I call fvwm
with startx, and once again my screen is 1024x768.


On Monday, December 19, 2022 9:49 PM, Timothy M Butterworth wrote:

Newer Intel graphics require closed source binary blobs. Try installing
firmware-linux-nonfree.


I did that and am still stuck.  Thanks for the suggestion.

On Monday, December 19, 2022 10:29 PM, Felix Miata  
replied:

Cardinal rule of PC shopping for use with Linux, unless you are a Linux
developer:
   Make sure the major PC components are several months or more older than
   your selected distro's original release date.


I've heard that rule often but trusted a local friend who's built many Linux
machines to build mine.  I've used *ix for 40 years but never assembled the
hardware.  And here I am.


To use Bullseye, at the least you need either a backport kernel containing
Alder Lake support, or Bookworm (Testing) or Sid (Unstable).


I'll try Testing and, if that fails, maybe an add-on graphics card.  Thanks.

On Tuesday, December 20, 2022 2:47 AM, Bret Busby  wrote:

Perhaps, it would be worthwhile, to download and try a Linux Mint live iso,


Thank you.  I hope to stick with Debian but will keep this in mind.



Another possibility comes to mind because there are cheap one way cables 
out there, just waiting to snag some shekels from the relatively new 
bee.  So you might be able to get the get-edid to work with a different 
cable that is all there for 2 way traffic. There is also the possibility 
the monitor is too old to have an edid response but that is only a 
suspect if it is over a decade old.


On Tuesday, December 20, 2022 10:36 AM, Max Nikulin wrote:Or 

get-edid | parse-edid
edid-decode /sys/class/drm/card0-HDMI-A-1/edid

Thanks.  get-edid doesn't find any EDIDs, and there are no edid files under
/sys/devices.


From: Max Nikulin 
Sent: Tuesday, December 20, 2022 10:36 AM
To: debian-user@lists.debian.org
Subject: Re: loss of screen resolution, part 2

External Email: Use Caution


On 20/12/2022 09:49, Timothy M Butterworth wrote:

Newer Intel graphics require closed source binary blobs. Try installing
firmware-linux-nonfree.


In the previous thread somebody spotted an issue with fetching modes
supported by the monitor. Examples of commands to debug such problem:

get-edid | parse-edid
edid-decode /sys/class/drm/card0-HDMI-A-1/edid


.


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

Re: loss of screen resolution, part 2

[Max Nikulin]

On 21/12/2022 00:26, Kleene, Steven (kleenesj) wrote:

On Tuesday, December 20, 2022 10:36 AM, Max Nikulin wrote:

get-edid | parse-edid
edid-decode /sys/class/drm/card0-HDMI-A-1/edid

Thanks.  get-edid doesn't find any EDIDs, and there are no edid files under
/sys/devices.


Have you checked "journalctl -b" (current boot only) output for messages 
related to missing firmware? It may be noticeable in "apt upgrade" 
messages when initramfs is created during installing of new kernel.


As an experiment (it is better to remove new file or restore old 
version) latest firmware files may be taken from

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree
Such changes usually requires "update-initramfs -u" (normally performed 
by scripts insides firmware .deb packages).

Re: loss of screen resolution, part 2

[Kleene, Steven (kleenesj)]

On Wednesday, December 21, 2022 3:37 AM, to...@tuxteam.de  
wrote:
> Could it just be that the microcontroller (in the display) responsible for
> providing the EDID is dead?

That might have seemed like a good explanation when I saw it with the older
desktop, but now it seems unlikely.  With the new desktop running Testing,
the monitor works and there is an edid file under /sys/devices.  Thanks.

I forgot to mention last time how impressed and grateful I am that the
developers got support for this new motherboard implemented as fast as they
did.


From: to...@tuxteam.de 
Sent: Wednesday, December 21, 2022 3:37 AM
To: debian-user@lists.debian.org
Subject: Re: loss of screen resolution, part 2

External Email: Use Caution

Re: loss of screen resolution, part 2

[tomas]

On Tue, Dec 20, 2022 at 05:26:06PM +, Kleene, Steven (kleenesj) wrote:

[...]

> On Tuesday, December 20, 2022 10:36 AM, Max Nikulin wrote:
> > get-edid | parse-edid
> > edid-decode /sys/class/drm/card0-HDMI-A-1/edid
> Thanks.  get-edid doesn't find any EDIDs, and there are no edid files under
> /sys/devices.

Could it just be that the microcontroller (in the display)
responsible for providing the EDID is dead? 

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: loss of screen resolution, part 2

[Kleene, Steven (kleenesj)]

On Monday, December 19, 2022 9:12 PM, I wrote:
>> Today I have my new desktop and did a clean install of Bullseye.  I call fvwm
>> with startx, and once again my screen is 1024x768.

On Monday, December 19, 2022 10:29 PM, Felix Miata  
replied:
> To use Bullseye, at the least you need either a backport kernel containing
> Alder Lake support, or Bookworm (Testing) or Sid (Unstable).

I did a clean install of Bookworm and am happy to report that solved the
problem.  Thank you.


From: Kleene, Steven (kleenesj) 
Sent: Tuesday, December 20, 2022 12:26 PM
To: debian-user@lists.debian.org
Subject: Re: loss of screen resolution, part 2

On Monday, December 19, 2022 9:12 PM, I wrote:
>> Today I have my new desktop and did a clean install of Bullseye.  I call fvwm
>> with startx, and once again my screen is 1024x768.

On Monday, December 19, 2022 9:49 PM, Timothy M Butterworth wrote:
> Newer Intel graphics require closed source binary blobs. Try installing
> firmware-linux-nonfree.

I did that and am still stuck.  Thanks for the suggestion.

On Monday, December 19, 2022 10:29 PM, Felix Miata  
replied:
> Cardinal rule of PC shopping for use with Linux, unless you are a Linux
> developer:
>   Make sure the major PC components are several months or more older than
>   your selected distro's original release date.

I've heard that rule often but trusted a local friend who's built many Linux
machines to build mine.  I've used *ix for 40 years but never assembled the
hardware.  And here I am.

> To use Bullseye, at the least you need either a backport kernel containing
> Alder Lake support, or Bookworm (Testing) or Sid (Unstable).

I'll try Testing and, if that fails, maybe an add-on graphics card.  Thanks.

On Tuesday, December 20, 2022 2:47 AM, Bret Busby  wrote:
> Perhaps, it would be worthwhile, to download and try a Linux Mint live iso,

Thank you.  I hope to stick with Debian but will keep this in mind.

On Tuesday, December 20, 2022 10:36 AM, Max Nikulin wrote:
> get-edid | parse-edid
> edid-decode /sys/class/drm/card0-HDMI-A-1/edid
Thanks.  get-edid doesn't find any EDIDs, and there are no edid files under
/sys/devices.


From: Max Nikulin 
Sent: Tuesday, December 20, 2022 10:36 AM
To: debian-user@lists.debian.org
Subject: Re: loss of screen resolution, part 2

External Email: Use Caution


On 20/12/2022 09:49, Timothy M Butterworth wrote:
> Newer Intel graphics require closed source binary blobs. Try installing
> firmware-linux-nonfree.

In the previous thread somebody spotted an issue with fetching modes
supported by the monitor. Examples of commands to debug such problem:

get-edid | parse-edid
edid-decode /sys/class/drm/card0-HDMI-A-1/edid

Re: loss of screen resolution, part 2

[Kleene, Steven (kleenesj)]

On Monday, December 19, 2022 9:12 PM, I wrote:
>> Today I have my new desktop and did a clean install of Bullseye.  I call fvwm
>> with startx, and once again my screen is 1024x768.

On Monday, December 19, 2022 9:49 PM, Timothy M Butterworth wrote:
> Newer Intel graphics require closed source binary blobs. Try installing
> firmware-linux-nonfree.

I did that and am still stuck.  Thanks for the suggestion.

On Monday, December 19, 2022 10:29 PM, Felix Miata  
replied:
> Cardinal rule of PC shopping for use with Linux, unless you are a Linux
> developer:
>   Make sure the major PC components are several months or more older than
>   your selected distro's original release date.

I've heard that rule often but trusted a local friend who's built many Linux
machines to build mine.  I've used *ix for 40 years but never assembled the
hardware.  And here I am.

> To use Bullseye, at the least you need either a backport kernel containing
> Alder Lake support, or Bookworm (Testing) or Sid (Unstable).

I'll try Testing and, if that fails, maybe an add-on graphics card.  Thanks.

On Tuesday, December 20, 2022 2:47 AM, Bret Busby  wrote:
> Perhaps, it would be worthwhile, to download and try a Linux Mint live iso,

Thank you.  I hope to stick with Debian but will keep this in mind.

On Tuesday, December 20, 2022 10:36 AM, Max Nikulin wrote:
> get-edid | parse-edid
> edid-decode /sys/class/drm/card0-HDMI-A-1/edid
Thanks.  get-edid doesn't find any EDIDs, and there are no edid files under
/sys/devices.


From: Max Nikulin 
Sent: Tuesday, December 20, 2022 10:36 AM
To: debian-user@lists.debian.org
Subject: Re: loss of screen resolution, part 2

External Email: Use Caution


On 20/12/2022 09:49, Timothy M Butterworth wrote:
> Newer Intel graphics require closed source binary blobs. Try installing
> firmware-linux-nonfree.

In the previous thread somebody spotted an issue with fetching modes
supported by the monitor. Examples of commands to debug such problem:

get-edid | parse-edid
edid-decode /sys/class/drm/card0-HDMI-A-1/edid

Re: loss of screen resolution, part 2

[Max Nikulin]

On 20/12/2022 09:49, Timothy M Butterworth wrote:
Newer Intel graphics require closed source binary blobs. Try installing 
firmware-linux-nonfree.


In the previous thread somebody spotted an issue with fetching modes 
supported by the monitor. Examples of commands to debug such problem:


get-edid | parse-edid
edid-decode /sys/class/drm/card0-HDMI-A-1/edid

Re: loss of screen resolution, part 2

[Felix Miata]

Kleene, Steven (kleenesj) composed on 2022-12-20 02:12 (UTC):

> Today I have my new desktop and did a clean install of Bullseye.

Cardinal rule of PC shopping for use with Linux, unless you are a Linux 
developer:

Make sure the major PC components are several months or more older than
your selected distro's original release date.

> lspci | grep VGA
> 00:02.0 VGA compatible controller: Intel Corporation Device 4692 (rev 0c)

https://pci-ids.ucw.cz/read/PC/8086/4692
https://en.wikipedia.org/wiki/Alder_Lake
"Intel officially announced 12th Gen Intel Core CPUs on October 27, 2021. Intel
officially announced 12th Gen Intel Core mobile CPUs and non-K series desktop 
CPUs
on January 4, 2022. ... Alder Lake."

>   Desktop: FVWM v: 2.6.8 vt: 1 dm: startx Distro: Debian GNU/Linux 11
> (bullseye)
> Graphics:
>   Device-1: Intel vendor: ASUSTeK driver: N/A arch: Gen-12.2
> process: Intel 10nm built: 2021-22+ bus-ID: 00:02.0 chip-ID: 8086:4692

https://en.wikipedia.org/wiki/Debian_version_history#Debian_11_(Bullseye)
"Debian 11 (Bullseye) was released on 14 August 2021.[1] It is based on the 
Linux
5.10 LTS kernel and will be supported for five years.[187]"

Your situation is backwards, distro released (2021) long before the hardware
(2022). Thus, out-of-the-box Bullseye can't be expected to support your GPU. To
use Bullseye, at the least you need either a backport kernel containing Alder 
Lake
support, or Bookworm (Testing) or Sid (Unstable).
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: loss of screen resolution, part 2

[Timothy M Butterworth]

On Mon, Dec 19, 2022 at 9:28 PM Kleene, Steven (kleenesj) <
kleen...@ucmail.uc.edu> wrote:

> On Thursday, December 1, 2022 9:41 PM, I started a thread (same title as
> this
> minus "part 2"), with:
> > Out of the blue today, my usual screen resolution (1920x1200) became
> > unavailable.
>
> Despite many helpful suggestions, the problem wasn't resolved.  Since I
> was about to get a new desktop, I figured I could give up.  This history
> may
> all be irrelevant.
>
> Today I have my new desktop and did a clean install of Bullseye.  I call
> fvwm
> with startx, and once again my screen is 1024x768.  New desktop, new cable,
> same monitor (Dell U2412Mb), now connected DVI to Display Port.  I tested
> another Dell monitor connected HDMI to HDMI and had the same problem, so I
> don't guess the problem is in the monitor.
>
> The system sees the monitor as "default" rather than VGA, DP, DVI, or HDMI.
> I was able to define a new mode 1920x1200 with xrandr, but xrandr --addmode
> fails because I can't find an "output name" that works.  At the bottom are
> some of the outputs that were requested in the previous thread.
>
> On the motherboard (ASUS - Z790M-PLUS Prime D4 Intel LGA 1700 microATX),
> the
> NIC is apparently not supported yet by Debian, and I had to put in a second
> NIC.  Do I have to add a graphics card too now to get 1920x1200?
>
> Thanks.
>
> cat /etc/debian_version
> 11.6
>
> lspci | grep VGA
> 00:02.0 VGA compatible controller: Intel Corporation Device 4692 (rev 0c)
>
> dpkg --get-selections | grep firmware
> firmware-linux-free install
>
> dpkg --get-selections | grep xserver-xorg-video-*
> xserver-xorg-video-all  install
> xserver-xorg-video-amdgpu   install
> xserver-xorg-video-ati  install
> xserver-xorg-video-fbdevinstall
> xserver-xorg-video-intelinstall
> xserver-xorg-video-nouveau  install
> xserver-xorg-video-qxl  install
> xserver-xorg-video-radeon   install
> xserver-xorg-video-vesa install
> xserver-xorg-video-vmware   install
>

Newer Intel graphics require closed source binary blobs. Try installing
firmware-linux-nonfree.


> grep Driver  /var/log/Xorg.0.log | grep II
> [52.843] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
>
> inxi -GSaz
> System:
>   Kernel: 5.10.0-20-amd64 arch: x86_64 bits: 64 compiler: gcc v: 10.2.1
> parameters: BOOT_IMAGE=/boot/vmlinuz-5.10.0-20-amd64
> root=UUID=82fc750d-98f2-4096-9d84-17a2690d1dcf ro quiet
>   Desktop: FVWM v: 2.6.8 vt: 1 dm: startx Distro: Debian GNU/Linux 11
> (bullseye)
> Graphics:
>   Device-1: Intel vendor: ASUSTeK driver: N/A arch: Gen-12.2
> process: Intel 10nm built: 2021-22+ bus-ID: 00:02.0 chip-ID: 8086:4692
> class-ID: 0300
>   Display: server: X.Org v: 1.20.11 driver: X: loaded: vesa
> unloaded: fbdev,modesetting dri: swrast gpu: N/A display-ID: :0
> screens: 1
>   Screen-1: 0 s-res: 1024x768 s-dpi: 96 s-size: 271x203mm (10.67x7.99")
> s-diag: 339mm (13.33")
>   Monitor-1: default res: 1024x768 hz: 76 size: N/A modes: N/A
>   API: OpenGL v: 4.5 Mesa 20.3.5 renderer: llvmpipe (LLVM 11.0.1 256 bits)
> compat-v: 3.1 direct render: Yes
>
> cat ~/.local/share/xorg/Xorg.0.log | pastebinit
> https://paste.debian.net/1264692/
>


-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

loss of screen resolution, part 2

[Kleene, Steven (kleenesj)]

On Thursday, December 1, 2022 9:41 PM, I started a thread (same title as this
minus "part 2"), with:
> Out of the blue today, my usual screen resolution (1920x1200) became
> unavailable.

Despite many helpful suggestions, the problem wasn't resolved.  Since I
was about to get a new desktop, I figured I could give up.  This history may
all be irrelevant.

Today I have my new desktop and did a clean install of Bullseye.  I call fvwm
with startx, and once again my screen is 1024x768.  New desktop, new cable,
same monitor (Dell U2412Mb), now connected DVI to Display Port.  I tested
another Dell monitor connected HDMI to HDMI and had the same problem, so I
don't guess the problem is in the monitor.

The system sees the monitor as "default" rather than VGA, DP, DVI, or HDMI.
I was able to define a new mode 1920x1200 with xrandr, but xrandr --addmode
fails because I can't find an "output name" that works.  At the bottom are
some of the outputs that were requested in the previous thread.

On the motherboard (ASUS - Z790M-PLUS Prime D4 Intel LGA 1700 microATX), the
NIC is apparently not supported yet by Debian, and I had to put in a second
NIC.  Do I have to add a graphics card too now to get 1920x1200?

Thanks.

cat /etc/debian_version
11.6

lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Device 4692 (rev 0c)

dpkg --get-selections | grep firmware
firmware-linux-free install

dpkg --get-selections | grep xserver-xorg-video-*
xserver-xorg-video-all  install
xserver-xorg-video-amdgpu   install
xserver-xorg-video-ati  install
xserver-xorg-video-fbdevinstall
xserver-xorg-video-intelinstall
xserver-xorg-video-nouveau  install
xserver-xorg-video-qxl  install
xserver-xorg-video-radeon   install
xserver-xorg-video-vesa install
xserver-xorg-video-vmware   install

grep Driver  /var/log/Xorg.0.log | grep II
[52.843] (II) modesetting: Driver for Modesetting Kernel Drivers: kms

inxi -GSaz
System:
  Kernel: 5.10.0-20-amd64 arch: x86_64 bits: 64 compiler: gcc v: 10.2.1
parameters: BOOT_IMAGE=/boot/vmlinuz-5.10.0-20-amd64
root=UUID=82fc750d-98f2-4096-9d84-17a2690d1dcf ro quiet
  Desktop: FVWM v: 2.6.8 vt: 1 dm: startx Distro: Debian GNU/Linux 11
(bullseye)
Graphics:
  Device-1: Intel vendor: ASUSTeK driver: N/A arch: Gen-12.2
process: Intel 10nm built: 2021-22+ bus-ID: 00:02.0 chip-ID: 8086:4692
class-ID: 0300
  Display: server: X.Org v: 1.20.11 driver: X: loaded: vesa
unloaded: fbdev,modesetting dri: swrast gpu: N/A display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1024x768 s-dpi: 96 s-size: 271x203mm (10.67x7.99")
s-diag: 339mm (13.33")
  Monitor-1: default res: 1024x768 hz: 76 size: N/A modes: N/A
  API: OpenGL v: 4.5 Mesa 20.3.5 renderer: llvmpipe (LLVM 11.0.1 256 bits)
compat-v: 3.1 direct render: Yes

cat ~/.local/share/xorg/Xorg.0.log | pastebinit
https://paste.debian.net/1264692/

Re: loss of screen resolution

[Kleene, Steven (kleenesj)]

On December 1, 2022 9:41 PM, I wrote:
>> Out of the blue today, my usual screen resolution (1920x1200) became
>> unavailable. ...

On Sunday, December 4, 2022 1:26 AM, Felix Miata 
replied:
> Do you have another VGA cable you could try? Do you have any other PCs with
> VGA output available that you could test with your display?

My cable has one end male and one female, and I don't have a spare or a
useful adapter.  I tried swapping in another monitor using the cable from the
problem build.  The resolution problem persisted.  So the cable is still
a suspect.

On Sunday, December 4, 2022 8:22 PM, Felix Miata 
replied:
> Save the following as /etc/X11/xorg.conf.d/40-vga.conf:
>
> Section "Monitor"
> Identifier "DefaultMonitor"
> VendorName  "Dell"
> ModelName   "U2412M"
> HorizSync   30-83
> VertRefresh 50-61
> Option  "PreferredMode" "1920x1200"
> EndSection

Thanks.  I tried that and was again unsuccessful.

I guess this is in software or in the cable.  I could buy another cable, but
I'm the process of getting a new desktop built anyway.  I think I'll just
live with this until I can abandon ship.

Thanks for all your efforts, Felix.  I did learn a few things.


From: Felix Miata 
Sent: Sunday, December 4, 2022 8:22 PM
To: debian-user@lists.debian.org
Subject: Re: loss of screen resolution

External Email: Use Caution


Kleene, Steven (kleenesj) composed on 2022-12-04 18:03 (UTC):

> I do have /usr/lib/xserver-xorg-video-intel.  I don't have
> /etc/X11/xorg.conf.d/ but do have /usr/share/X11/xorg.conf.d/ with the
> following:
>   10-amdgpu.conf  10-quirks.conf  10-radeon.conf  40-libinput.conf  
> 70-wacom.conf
> It wasn't obvious to me that these were relevant.

> I don't have any useful spare hardware at home, although I do at work.  I
> could steal a VGA cable to test here.

If nothing yet suggested works, a more flexible solution than a manually 
generated
& hard-coded modeline applied after X has already started is letting the server
generate one on startup based upon the formerly provided EDID basics I retrieved
from your old Xorg.0.log:

Ranges: V min: 50 V max: 61 Hz, H min: 30 H max: 83 kHz

Save the following as /etc/X11/xorg.conf.d/40-vga.conf:

Section "Monitor"
Identifier "DefaultMonitor"
VendorName  "Dell"
ModelName   "U2412M"
HorizSync   30-83
VertRefresh 50-61
Option  "PreferredMode" "1920x1200"
EndSection

This early application ought to make it behave more like it used to, unless the
problem is actually inside the display. I've had two 1920x1200s die on me, a 
Dell
made in 2005 and a Lenovo made in 2009. My 2560x1080 Dell only lasted 5 years
before refusing to power on any more. :~( The two 1920x1200 I have now are 2011
NEC and 2012 Samsung.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: loss of screen resolution

[Felix Miata]

Kleene, Steven (kleenesj) composed on 2022-12-04 18:03 (UTC):

> I do have /usr/lib/xserver-xorg-video-intel.  I don't have
> /etc/X11/xorg.conf.d/ but do have /usr/share/X11/xorg.conf.d/ with the
> following:
>   10-amdgpu.conf  10-quirks.conf  10-radeon.conf  40-libinput.conf  
> 70-wacom.conf
> It wasn't obvious to me that these were relevant.

> I don't have any useful spare hardware at home, although I do at work.  I
> could steal a VGA cable to test here.

If nothing yet suggested works, a more flexible solution than a manually 
generated
& hard-coded modeline applied after X has already started is letting the server
generate one on startup based upon the formerly provided EDID basics I retrieved
from your old Xorg.0.log:

Ranges: V min: 50 V max: 61 Hz, H min: 30 H max: 83 kHz

Save the following as /etc/X11/xorg.conf.d/40-vga.conf:

Section "Monitor"
Identifier "DefaultMonitor"
VendorName  "Dell"
ModelName   "U2412M"
HorizSync   30-83
VertRefresh 50-61
Option  "PreferredMode" "1920x1200"
EndSection

This early application ought to make it behave more like it used to, unless the
problem is actually inside the display. I've had two 1920x1200s die on me, a 
Dell
made in 2005 and a Lenovo made in 2009. My 2560x1080 Dell only lasted 5 years
before refusing to power on any more. :~( The two 1920x1200 I have now are 2011
NEC and 2012 Samsung.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: loss of screen resolution

[Kleene, Steven (kleenesj)]

On December 1, 2022 9:41 PM, I wrote:
>> Out of the blue today, my usual screen resolution (1920x1200) became
>> unavailable. ...

On December 4, 2022 1:26 AM, Felix Miata  replied:
> Your old Xorg.0.logs differ significantly from your current ones ...
> This suggests to me your EDID is currently being misread or is incomplete.
> Does your VGA cable have 15 pins on both ends, or only 14? ...

It has 14 pins.  This monitor and cable have worked fine since 2014 with this
desktop running Debian.  About a week before the problem started, I did
disconnect the VGA cable from the desktop input.  I just reseated it
carefully and even rebooted, but that didn't fix the problem.  Maybe I fried
something messing with the connection.

I can confirm that my /var/log/Xorg.0.log (Jul  3  2021) has the EDID content
while ~/.local/share/xorg/Xorg.0.log (Dec  4 11:57) does not.

> Something to try: switch display driver from modesetting to intel. If
> xserver-xorg-video-intel is not installed, it should be used automatically if
> you install it. If it's already installed, then likely there's a .conf file
> in /etc/X11/xorg.conf.d/ specifically calling it that you could switch to
> calling intel instead.

I do have /usr/lib/xserver-xorg-video-intel.  I don't have
/etc/X11/xorg.conf.d/ but do have /usr/share/X11/xorg.conf.d/ with the
following:
  10-amdgpu.conf  10-quirks.conf  10-radeon.conf  40-libinput.conf  
70-wacom.conf
It wasn't obvious to me that these were relevant.

I don't have any useful spare hardware at home, although I do at work.  I
could steal a VGA cable to test here.

Thanks again.


From: Felix Miata 
Sent: Sunday, December 4, 2022 1:26 AM
To: debian-user@lists.debian.org
Subject: Re: loss of screen resolution

External Email: Use Caution


Kleene, Steven (kleenesj) composed on 2022-12-02 02:41 (UTC):
...
Your old Xorg.0.logs differ significantly from your current ones, and my
own on a similar Intel GPU. In what follows, the current ones and the old
ones omit everything between the first and last lines:

*
[  2059.607] (II) modeset(0): EDID for output VGA-1
[  2059.607] (II) modeset(0): Manufacturer: DEL  Model: a079  Serial#: 810693964
[  2059.607] (II) modeset(0): Year: 2014  Week: 24
[  2059.607] (II) modeset(0): EDID Version: 1.3
[  2059.607] (II) modeset(0): Analog Display Input,  Input Voltage Level: 
0.700/0.300 V
[  2059.607] (II) modeset(0): Sync:  Separate  Composite  SyncOnGreen
[  2059.607] (II) modeset(0): Max Image Size [cm]: horiz.: 52  vert.: 32
[  2059.607] (II) modeset(0): Gamma: 2.20
[  2059.607] (II) modeset(0): DPMS capabilities: StandBy Suspend Off; RGB/Color 
Display
[  2059.607] (II) modeset(0): First detailed timing is preferred mode
[  2059.607] (II) modeset(0): redX: 0.640 redY: 0.330   greenX: 0.300 greenY: 
0.600
[  2059.607] (II) modeset(0): blueX: 0.150 blueY: 0.060   whiteX: 0.313 whiteY: 
0.329
[  2059.607] (II) modeset(0): Supported established timings:
[  2059.607] (II) modeset(0): 720x400@70Hz
[  2059.607] (II) modeset(0): 640x480@60Hz
[  2059.607] (II) modeset(0): 800x600@60Hz
[  2059.607] (II) modeset(0): 1024x768@60Hz
[  2059.607] (II) modeset(0): Manufacturer's mask: 0
[  2059.607] (II) modeset(0): Supported standard timings:
[  2059.607] (II) modeset(0): #0: hsize: 1280  vsize 960  refresh: 60  vid: 
16513
[  2059.607] (II) modeset(0): #1: hsize: 1280  vsize 1024  refresh: 60  vid: 
32897
[  2059.607] (II) modeset(0): #2: hsize: 1600  vsize 1200  refresh: 60  vid: 
16553
[  2059.607] (II) modeset(0): #3: hsize: 1680  vsize 1050  refresh: 60  vid: 179
[  2059.607] (II) modeset(0): #4: hsize: 1920  vsize 1080  refresh: 60  vid: 
49361
[  2059.607] (II) modeset(0): Supported detailed timing:
[  2059.607] (II) modeset(0): clock: 154.0 MHz   Image Size:  518 x 324 mm
[  2059.607] (II) modeset(0): h_active: 1920  h_sync: 1968  h_sync_end 2000 
h_blank_end 2080 h_border: 0
[  2059.607] (II) modeset(0): v_active: 1200  v_sync: 1203  v_sync_end 1209 
v_blanking: 1235 v_border: 0
[  2059.607] (II) modeset(0): Serial No: YMYH146D0R5L
[  2059.607] (II) modeset(0): Monitor name: DELL U2412M
[  2059.608] (II) modeset(0): Ranges: V min: 50 V max: 61 Hz, H min: 30 H max: 
83 kHz, PixClock max 175 MHz
[  2059.608] (II) modeset(0): EDID (in hex):
[  2059.608] (II) modeset(0):   000010ac79a04c355230
[  2059.608] (II) modeset(0):   181801030e342078eaee95a3544c9926
[  2059.608] (II) modeset(0):   0f5054a1080081408180a940b300d1c0
[  2059.608] (II) modeset(0):   010101010101283c80a070b023403020
[  2059.608] (II) modeset(0):   36000644211a00ff00594d59
[  2059.608] (II) modeset(0):   48313436443052354c0a00fc0044
[  2059.608] (II) modeset(0):   454c4c2055323431324d0a2000fd
[  2059.608] (II) modeset(0):   00323d1e5311000a2020202020200092
[  2059.608] (II) modeset(0): Printing probed modes for output VGA-1
*

This suggests to me your EDID is currently being misread or is incomple

Re: loss of screen resolution

[Felix Miata]

Kleene, Steven (kleenesj) composed on 2022-12-02 02:41 (UTC):
... 
Your old Xorg.0.logs differ significantly from your current ones, and my
own on a similar Intel GPU. In what follows, the current ones and the old
ones omit everything between the first and last lines:

*
[  2059.607] (II) modeset(0): EDID for output VGA-1
[  2059.607] (II) modeset(0): Manufacturer: DEL  Model: a079  Serial#: 810693964
[  2059.607] (II) modeset(0): Year: 2014  Week: 24
[  2059.607] (II) modeset(0): EDID Version: 1.3
[  2059.607] (II) modeset(0): Analog Display Input,  Input Voltage Level: 
0.700/0.300 V
[  2059.607] (II) modeset(0): Sync:  Separate  Composite  SyncOnGreen
[  2059.607] (II) modeset(0): Max Image Size [cm]: horiz.: 52  vert.: 32
[  2059.607] (II) modeset(0): Gamma: 2.20
[  2059.607] (II) modeset(0): DPMS capabilities: StandBy Suspend Off; RGB/Color 
Display
[  2059.607] (II) modeset(0): First detailed timing is preferred mode
[  2059.607] (II) modeset(0): redX: 0.640 redY: 0.330   greenX: 0.300 greenY: 
0.600
[  2059.607] (II) modeset(0): blueX: 0.150 blueY: 0.060   whiteX: 0.313 whiteY: 
0.329
[  2059.607] (II) modeset(0): Supported established timings:
[  2059.607] (II) modeset(0): 720x400@70Hz
[  2059.607] (II) modeset(0): 640x480@60Hz
[  2059.607] (II) modeset(0): 800x600@60Hz
[  2059.607] (II) modeset(0): 1024x768@60Hz
[  2059.607] (II) modeset(0): Manufacturer's mask: 0
[  2059.607] (II) modeset(0): Supported standard timings:
[  2059.607] (II) modeset(0): #0: hsize: 1280  vsize 960  refresh: 60  vid: 
16513
[  2059.607] (II) modeset(0): #1: hsize: 1280  vsize 1024  refresh: 60  vid: 
32897
[  2059.607] (II) modeset(0): #2: hsize: 1600  vsize 1200  refresh: 60  vid: 
16553
[  2059.607] (II) modeset(0): #3: hsize: 1680  vsize 1050  refresh: 60  vid: 179
[  2059.607] (II) modeset(0): #4: hsize: 1920  vsize 1080  refresh: 60  vid: 
49361
[  2059.607] (II) modeset(0): Supported detailed timing:
[  2059.607] (II) modeset(0): clock: 154.0 MHz   Image Size:  518 x 324 mm
[  2059.607] (II) modeset(0): h_active: 1920  h_sync: 1968  h_sync_end 2000 
h_blank_end 2080 h_border: 0
[  2059.607] (II) modeset(0): v_active: 1200  v_sync: 1203  v_sync_end 1209 
v_blanking: 1235 v_border: 0
[  2059.607] (II) modeset(0): Serial No: YMYH146D0R5L
[  2059.607] (II) modeset(0): Monitor name: DELL U2412M
[  2059.608] (II) modeset(0): Ranges: V min: 50 V max: 61 Hz, H min: 30 H max: 
83 kHz, PixClock max 175 MHz
[  2059.608] (II) modeset(0): EDID (in hex):
[  2059.608] (II) modeset(0):   000010ac79a04c355230
[  2059.608] (II) modeset(0):   181801030e342078eaee95a3544c9926
[  2059.608] (II) modeset(0):   0f5054a1080081408180a940b300d1c0
[  2059.608] (II) modeset(0):   010101010101283c80a070b023403020
[  2059.608] (II) modeset(0):   36000644211a00ff00594d59
[  2059.608] (II) modeset(0):   48313436443052354c0a00fc0044
[  2059.608] (II) modeset(0):   454c4c2055323431324d0a2000fd
[  2059.608] (II) modeset(0):   00323d1e5311000a2020202020200092
[  2059.608] (II) modeset(0): Printing probed modes for output VGA-1
*

This suggests to me your EDID is currently being misread or is incomplete.
Does your VGA cable have 15 pins on both ends, or only 14? Do you have
another VGA cable you could try? Do you have any other PCs with VGA output
available that you could test with your display? Do you have a FullHD TV
with VGA input you could test 1920x1080 with? Perhaps your cable simply
could use a removal and refitting.

Something to try: switch display driver from modesetting to intel. If
xserver-xorg-video-intel is not installed, it should be used automatically
if you install it. If it's already installed, then likely there's a .conf
file in /etc/X11/xorg.conf.d/ specifically calling it that you could switch
to calling intel instead.

The modesetting display driver is newer technology developed in large part
by Intel's driver programmers, and is responsible for the intel display
driver not having an official release in nearly a decade. Sometimes it works
better, or at least works when the modesetting driver has a bug, but the
modesetting is actually the default for AMD, Intel, NVidia and all other GPUs
for which a KMS module exists.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: loss of screen resolution

[Felix Miata]

Kleene, Steven (kleenesj) composed on 2022-12-02 02:41 (UTC):

See if adding the following file helps:
---
# cat /etc/X11/xorg.conf.d/25-intelExtra.conf
Section "Device"
Identifier  "IntelKludges"
Option  "ReprobeOutputs" "on"   # default off
EndSection
---

"(WW) VGA arbiter: cannot open kernel arbiter, no multi-card support"
from your logs puzzles me. :( Is this in a VM?
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: loss of screen resolution

[Kleene, Steven (kleenesj)]

On December 1, 2022 9:41 PM, I wrote:

>> Out of the blue today, my usual screen resolution (1920x1200) became
>> unavailable. ...

On December 3, 2022 1:23 PM, Felix Miata  wrote:

> This and http://paste.debian.net/1262700/ are the same log created Sat Jul 3
> 16:37:19 2021 using kernel 4.19.0-17-amd64. If these are from /var/log/ then
> look in ~/.local/share/xorg/ for a current one.

Sorry, I should have noticed that.  Here are the contents of
~/.local/share/xorg/Xorg.0.log, first from the console after a fresh boot:
  http://paste.debian.net/1262763/
then after calling startx and coming up 1024x768:
  http://paste.debian.net/1262764/
and finally after using xrandr to get 1920x1200:
  http://paste.debian.net/1262765/

The second and third files only differ by one line at the end.  Thanks.


From: Felix Miata 
Sent: Saturday, December 3, 2022 1:23 PM
To: debian-user@lists.debian.org
Subject: Re: loss of screen resolution

External Email: Use Caution


Kleene, Steven (kleenesj) composed on 2022-12-03 14:15 (UTC):

> For Xorg.0.log,
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpaste.debian.net%2F1262735%2Fdata=05%7C01%7Ckleenesj%40ucmail.uc.edu%7Cfb8f5bce786f42dc921308dad55c42f3%7Cf5222e6c5fc648eb8f0373db18203b63%7C1%7C0%7C638056889486652349%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=cEu7XkZUJn3VOTiLcdvcVEvidGKsA8RLvXd1kUf7oR8%3Dreserved=0

This and 
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpaste.debian.net%2F1262700%2Fdata=05%7C01%7Ckleenesj%40ucmail.uc.edu%7Cfb8f5bce786f42dc921308dad55c42f3%7Cf5222e6c5fc648eb8f0373db18203b63%7C1%7C0%7C638056889486652349%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=6zqt%2FcKItF3u%2BCd7nzEQOizl9DeiksEDaNBS6BHpUb0%3Dreserved=0
 are the same log created
Sat Jul 3 16:37:19 2021 using kernel 4.19.0-17-amd64. If these are from 
/var/log/
then look in ~/.local/share/xorg/ for a current one.

Current kernel is 4.19.0-22-amd64.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: loss of screen resolution

[Felix Miata]

Kleene, Steven (kleenesj) composed on 2022-12-03 14:15 (UTC):

> For Xorg.0.log,
> http://paste.debian.net/1262735/

This and http://paste.debian.net/1262700/ are the same log created
Sat Jul 3 16:37:19 2021 using kernel 4.19.0-17-amd64. If these are from 
/var/log/
then look in ~/.local/share/xorg/ for a current one.

Current kernel is 4.19.0-22-amd64.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: loss of screen resolution

[Kleene, Steven (kleenesj)]

On December 1, 2022 9:41 PM, I wrote:
>>> Out of the blue today, my usual screen resolution (1920x1200) became
>>> unavailable. ...

On December 2, 2022 10:12 AM, Felix Miata  wrote:
>> ... run
>> inxi -U
>> to upgrade, and post here output from within an X terminal:
>> inxi -GSaz
>> ...
>> Next, give us the whole log to see:
cat /var/log/Xorg.0.log | pastebinit

And on December 3, 2022 1:14 AM, Felix Miata  added:

> Did these result after applying your xrandr workaround? If the problem
> remains in absence of the workaround, the inxi and log need to come from
> being in that condition.

I had done those after the workaround.  So I exited fvwm back to the console,
recalled fvwm via startx, and gathered the information again before doing the
workaround.
inxi ->
System:
  Kernel: 4.19.0-22-amd64 arch: x86_64 bits: 64 compiler: gcc v: 8.3.0
parameters: BOOT_IMAGE=/boot/vmlinuz-4.19.0-22-amd64
root=UUID=093750e2-4489-4550-a3fc-5e86b450320b ro quiet
  Desktop: FVWM v: 2.6.8 vt: 1 dm: startx Distro: Debian GNU/Linux 10
(buster)
Graphics:
  Device-1: Intel 82946GZ/GL Integrated Graphics driver: i915 v: kernel
arch: Gen-3.5 process: Intel 90nm built: 2005-06 ports: active: VGA-1
empty: none bus-ID: 00:02.0 chip-ID: 8086:2972 class-ID: 0300
  Display: server: X.Org v: 1.20.4 driver: X: loaded: modesetting
unloaded: fbdev,vesa dri: i965 gpu: i915 display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1024x768 s-dpi: 96 s-size: 270x203mm (10.63x7.99")
s-diag: 338mm (13.3")
  Monitor-1: VGA-1 res: 1024x768 hz: 60 size: N/A modes: max: 1024x768
min: 640x480
  API: OpenGL v: 2.1 Mesa 18.3.6 renderer: Mesa DRI Intel 946GZ
direct render: Yes

This is the same as before except showing 1024x768 instead of 1920x1200.

For Xorg.0.log,
http://paste.debian.net/1262735/

Thanks again.


From: Felix Miata 
Sent: Saturday, December 3, 2022 1:14 AM
To: debian-user@lists.debian.org
Subject: Re: loss of screen resolution

External Email: Use Caution


Kleene, Steven (kleenesj) composed on 2022-12-02 02:20 (UTC):

>> Next, give us the whole log to see:
> cat /var/log/Xorg.0.log | pastebinit

> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpaste.debian.net%2F1262700%2Fdata=05%7C01%7Ckleenesj%40ucmail.uc.edu%7Ccfc9a461f864488b9b7108dad4f5c190%7Cf5222e6c5fc648eb8f0373db18203b63%7C1%7C0%7C638056449240692027%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=pQ9QP%2BuDQ2%2BjbzxZB815Oo2YL8z022xO%2BTjkzHaH1%2BE%3Dreserved=0

> That's a lot to look at.  Thank you.

I don't see anything to suggest that there's anything wrong. Did these result
after applying your xrandr workaround? If the problem remains in absence of the
workaround, the inxi and log need to come from being in that condition. I have
something similar needing no correction or workaround:

# inxi -GSaz --vs --zl --hostname
inxi 3.3.23-00 (2022-10-31)
System:
  Host: gx62b Kernel: 4.19.0-22-amd64 arch: x86_64 bits: 64 compiler: gcc
v: 8.3.0 parameters: root=LABEL= ipv6.disable=1 net.ifnames=0
biosdevname=0 plymouth.enable=0 noresume mitigations=auto consoleblank=0
  Desktop: Trinity v: R14.0.13 tk: Qt v: 3.5.0 info: kicker wm: Twin v: 3.0
vt: 7 dm: 1: TDM 2: XDM Distro: Debian GNU/Linux 10 (buster)
Graphics:
  Device-1: Intel 82945G/GZ Integrated Graphics vendor: Dell driver: i915
v: kernel arch: Gen-3.5 process: Intel 90nm built: 2005-06 ports:
active: DVI-D-1,VGA-1 empty: none bus-ID: 00:02.0 chip-ID: 8086:2772
class-ID: 0300
  Display: x11 server: X.Org v: 1.20.4 driver: X: loaded: intel
unloaded: fbdev,modesetting,vesa dri: i915 gpu: i915 display-ID: :0
screens: 1
  Screen-1: 0 s-res: 3600x1200 s-dpi: 120 s-size: 762x254mm (30.00x10.00")
s-diag: 803mm (31.62")
  Monitor-1: DVI-D-1 mapped: DVI1 pos: primary,left model: NEC EA243WM
serial:  built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2
size: 520x320mm (20.47x12.6") diag: 612mm (24.1") ratio: 16:10 modes:
max: 1920x1200 min: 640x480
  Monitor-2: VGA-1 mapped: VGA1 pos: right model: Dell P2213
serial:  built: 2012 res: 1680x1050 hz: 60 dpi: 91 gamma: 1.2
size: 470x300mm (18.5x11.81") diag: 558mm (22") ratio: 16:10 modes:
max: 1680x1050 min: 720x400
  API: OpenGL v: 1.4 Mesa 18.3.6 renderer: Mesa DRI Intel 945G
direct render: Yes
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: loss of screen resolution

[Felix Miata]

Kleene, Steven (kleenesj) composed on 2022-12-02 02:20 (UTC):

>> Next, give us the whole log to see:
> cat /var/log/Xorg.0.log | pastebinit

> http://paste.debian.net/1262700/

> That's a lot to look at.  Thank you.

I don't see anything to suggest that there's anything wrong. Did these result
after applying your xrandr workaround? If the problem remains in absence of the
workaround, the inxi and log need to come from being in that condition. I have
something similar needing no correction or workaround:

# inxi -GSaz --vs --zl --hostname
inxi 3.3.23-00 (2022-10-31)
System:
  Host: gx62b Kernel: 4.19.0-22-amd64 arch: x86_64 bits: 64 compiler: gcc
v: 8.3.0 parameters: root=LABEL= ipv6.disable=1 net.ifnames=0
biosdevname=0 plymouth.enable=0 noresume mitigations=auto consoleblank=0
  Desktop: Trinity v: R14.0.13 tk: Qt v: 3.5.0 info: kicker wm: Twin v: 3.0
vt: 7 dm: 1: TDM 2: XDM Distro: Debian GNU/Linux 10 (buster)
Graphics:
  Device-1: Intel 82945G/GZ Integrated Graphics vendor: Dell driver: i915
v: kernel arch: Gen-3.5 process: Intel 90nm built: 2005-06 ports:
active: DVI-D-1,VGA-1 empty: none bus-ID: 00:02.0 chip-ID: 8086:2772
class-ID: 0300
  Display: x11 server: X.Org v: 1.20.4 driver: X: loaded: intel
unloaded: fbdev,modesetting,vesa dri: i915 gpu: i915 display-ID: :0
    screens: 1
  Screen-1: 0 s-res: 3600x1200 s-dpi: 120 s-size: 762x254mm (30.00x10.00")
s-diag: 803mm (31.62")
  Monitor-1: DVI-D-1 mapped: DVI1 pos: primary,left model: NEC EA243WM
serial:  built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2
size: 520x320mm (20.47x12.6") diag: 612mm (24.1") ratio: 16:10 modes:
max: 1920x1200 min: 640x480
  Monitor-2: VGA-1 mapped: VGA1 pos: right model: Dell P2213
serial:  built: 2012 res: 1680x1050 hz: 60 dpi: 91 gamma: 1.2
size: 470x300mm (18.5x11.81") diag: 558mm (22") ratio: 16:10 modes:
max: 1680x1050 min: 720x400
  API: OpenGL v: 1.4 Mesa 18.3.6 renderer: Mesa DRI Intel 945G
direct render: Yes
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: loss of screen resolution

[Kleene, Steven (kleenesj)]

On December 1, 2022 9:41 PM, I wrote:

>> Out of the blue today, my usual screen resolution (1920x1200) became
>> unavailable. ...

On December 2, 2022 10:12 AM, Felix Miata  wrote:

> ... run
> inxi -U
> to upgrade, and post here output from within an X terminal:
> inxi -GSaz

System:
  Kernel: 4.19.0-22-amd64 arch: x86_64 bits: 64 compiler: gcc v: 8.3.0
parameters: BOOT_IMAGE=/boot/vmlinuz-4.19.0-22-amd64
root=UUID=093750e2-4489-4550-a3fc-5e86b450320b ro quiet
  Desktop: FVWM v: 2.6.8 vt: 1 dm: startx Distro: Debian GNU/Linux 10
(buster)
Graphics:
  Device-1: Intel 82946GZ/GL Integrated Graphics driver: i915 v: kernel
arch: Gen-3.5 process: Intel 90nm built: 2005-06 ports: active: VGA-1
empty: none bus-ID: 00:02.0 chip-ID: 8086:2972 class-ID: 0300
  Display: server: X.Org v: 1.20.4 driver: X: loaded: modesetting
unloaded: fbdev,vesa dri: i965 gpu: i915 display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1920x1200 s-dpi: 96 s-size: 507x317mm (19.96x12.48")
s-diag: 598mm (23.54")
  Monitor-1: VGA-1 res: 1920x1200 hz: 60 size: N/A modes: max: 1024x768
min: 640x480
  API: OpenGL v: 2.1 Mesa 18.3.6 renderer: Mesa DRI Intel 946GZ
direct render: Yes

> Next, give us the whole log to see:
cat /var/log/Xorg.0.log | pastebinit

http://paste.debian.net/1262700/

That's a lot to look at.  Thank you.


From: Felix Miata 
Sent: Friday, December 2, 2022 10:12 AM
To: debian-user@lists.debian.org
Subject: Re: loss of screen resolution

External Email: Use Caution


Kleene, Steven (kleenesj) composed on 2022-12-02 13:11 (UTC):

> I'll add that I did do a weekly apt upgrade shortly before this happened,

Now let's see how all those things Dan asked for work together:

Install/Upgrade inxi. Buster's inxi is a broken antique. Best to install 
directly
from upstream. It's just a data collection and presentation script:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsmxi.org%2Fdocs%2Finxi-installation.htm%23inxi-manual-installdata=05%7C01%7Ckleenesj%40ucmail.uc.edu%7C0b895e40ae1845abc85b08dad477c4ea%7Cf5222e6c5fc648eb8f0373db18203b63%7C1%7C0%7C638055908118333462%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Od8tsIGlAhdF8HQbnDo2shuCpiPVRwr8jqATtd6vhhI%3Dreserved=0
To upgrade Debian's version, it's necessary to edit /etc/inxi.conf to remove the
upgrade blockage, so change B_ALLOW_UPDATE=false to B_ALLOW_UPDATE=true, then 
run

inxi -U

to upgrade, and post here output from within an X terminal:

inxi -GSaz

Next, give us the whole log to see:

cat /var/log/Xorg.0.log | pastebinit
or
cat ~/.local/share/xorg/Xorg.0.log | pastebinit

and provide the resulting URI here, or attach the file to your reply. Don't 
paste
its content into the email unless you know how to prevent line wrapping that 
makes
a mess of it.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: loss of screen resolution

[Felix Miata]

Kleene, Steven (kleenesj) composed on 2022-12-02 13:11 (UTC):

> I'll add that I did do a weekly apt upgrade shortly before this happened,

Now let's see how all those things Dan asked for work together:

Install/Upgrade inxi. Buster's inxi is a broken antique. Best to install 
directly
from upstream. It's just a data collection and presentation script:
https://smxi.org/docs/inxi-installation.htm#inxi-manual-install
To upgrade Debian's version, it's necessary to edit /etc/inxi.conf to remove the
upgrade blockage, so change B_ALLOW_UPDATE=false to B_ALLOW_UPDATE=true, then 
run

inxi -U

to upgrade, and post here output from within an X terminal:

inxi -GSaz

Next, give us the whole log to see:

cat /var/log/Xorg.0.log | pastebinit
or
cat ~/.local/share/xorg/Xorg.0.log | pastebinit

and provide the resulting URI here, or attach the file to your reply. Don't 
paste
its content into the email unless you know how to prevent line wrapping that 
makes
a mess of it.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: loss of screen resolution

[Kleene, Steven (kleenesj)]

On December 1, 2022 9:41 PM, I wrote:

>> Out of the blue today, my usual screen resolution (1920x1200) became
>> unavailable. ...

On December 2, 2022 7:43 AM, Dan Ritter  replied:

> I'm going to guess that this is a change in one or both of:
>
> - GPU firmware
> - X11 GPU driver
>
> Let's get the output from:
>
> cat /etc/debian_version

10.13

> lspci | grep VGA

00:02.0 VGA compatible controller: Intel Corporation 82946GZ/GL Integrated 
Graphics Controller (rev 02)

> dpkg --get-selections | grep firmware

firmware-linux-free install

> dpkg --get-selections | grep xserver-xorg-video-*

xserver-xorg-video-all  install
xserver-xorg-video-amdgpu   install
xserver-xorg-video-ati  install
xserver-xorg-video-fbdevinstall
xserver-xorg-video-intelinstall
xserver-xorg-video-nouveau  install
xserver-xorg-video-qxl  install
xserver-xorg-video-radeon   install
xserver-xorg-video-vesa install
xserver-xorg-video-vmware   install

> grep Driver  /var/log/Xorg.0.log|grep II

[  2059.194] (II) modesetting: Driver for Modesetting Kernel Drivers: kms

I'll add that I did do a weekly apt upgrade shortly before this happened, but
it's not obvious that any of the upgrades (firefox-esr grub-common grub-pc
grub-pc-bin grub2-common krb5-locales libgssapi-krb5-2 libgssapi-krb5-2:i386
libk5crypto3 libk5crypto3:i386 libkrb5-3 libkrb5-3:i386 libkrb5support0
libkrb5support0:i386 vim-common vim-tiny xxd) are relevant.

Thanks.


From: Dan Ritter 
Sent: Friday, December 2, 2022 7:43 AM
To: Kleene, Steven (kleenesj)
Cc: debian-user@lists.debian.org
Subject: Re: loss of screen resolution

External Email: Use Caution


Kleene, Steven (kleenesj) wrote:
> Out of the blue today, my usual screen resolution (1920x1200) became
> unavailable.  I booted to the console and called startx, which brings up
> fvwm.  But my default base window went way off-screen, and the type was huge.
> xrandr said I was at 1024x768 and did not list the 1920x1200 option at all.
> (It usually does.)  I was able to define and call that option in my base
> window with:
>
> xrandr --newmode "1920x1200_60.00"  193.25  1920 2056 2256 2592  1200 1203 
> 1209 1245 -hsync +vsync
> xrandr --addmode VGA-1 1920x1200_60.00
> xrandr --output VGA-1 --mode 1920x1200_60.00
>
> This gave me my usual window and font size, but there are some side issues
> (e.g. where icons go when I minimize them).
>
> In any case, I think the problem is upstream of X windows.  I boot to a
> console, and the font there was much bigger than usual.  Where is that
> controlled?  Any idea how to get this back to normal?  The monitor is set to
> an aspect ratio of 16:1.  Resetting the monitor and rebooting did not fix
> the problem.

I'm going to guess that this is a change in one or both of:

- GPU firmware
- X11 GPU driver

Let's get the output from:

cat /etc/debian_version
to find out what you're running

lspci | grep VGA
to find out what your graphics hardware is

dpkg --get-selections | grep firmware
to find out what firmware is installed

dpkg --get-selections | grep xserver-xorg-video-*
to find out whether the right video driver is installed

and finally,

grep Driver  /var/log/Xorg.0.log|grep II

or if that file is missing,

grep Driver ~/.local/share/xorg/Xorg.0.log | grep II

to find out what driver is actually being used

-dsr-

Re: loss of screen resolution

[Dan Ritter]

Kleene, Steven (kleenesj) wrote: 
> Out of the blue today, my usual screen resolution (1920x1200) became
> unavailable.  I booted to the console and called startx, which brings up
> fvwm.  But my default base window went way off-screen, and the type was huge.
> xrandr said I was at 1024x768 and did not list the 1920x1200 option at all.
> (It usually does.)  I was able to define and call that option in my base
> window with:
> 
> xrandr --newmode "1920x1200_60.00"  193.25  1920 2056 2256 2592  1200 1203 
> 1209 1245 -hsync +vsync
> xrandr --addmode VGA-1 1920x1200_60.00
> xrandr --output VGA-1 --mode 1920x1200_60.00
> 
> This gave me my usual window and font size, but there are some side issues
> (e.g. where icons go when I minimize them).
> 
> In any case, I think the problem is upstream of X windows.  I boot to a
> console, and the font there was much bigger than usual.  Where is that
> controlled?  Any idea how to get this back to normal?  The monitor is set to
> an aspect ratio of 16:1.  Resetting the monitor and rebooting did not fix
> the problem.

I'm going to guess that this is a change in one or both of:

- GPU firmware
- X11 GPU driver

Let's get the output from:

cat /etc/debian_version
to find out what you're running

lspci | grep VGA
to find out what your graphics hardware is

dpkg --get-selections | grep firmware
to find out what firmware is installed

dpkg --get-selections | grep xserver-xorg-video-*
to find out whether the right video driver is installed

and finally,

grep Driver  /var/log/Xorg.0.log|grep II

or if that file is missing,

grep Driver ~/.local/share/xorg/Xorg.0.log | grep II

to find out what driver is actually being used

-dsr-

loss of screen resolution

[Kleene, Steven (kleenesj)]

Out of the blue today, my usual screen resolution (1920x1200) became
unavailable.  I booted to the console and called startx, which brings up
fvwm.  But my default base window went way off-screen, and the type was huge.
xrandr said I was at 1024x768 and did not list the 1920x1200 option at all.
(It usually does.)  I was able to define and call that option in my base
window with:

xrandr --newmode "1920x1200_60.00"  193.25  1920 2056 2256 2592  1200 1203 1209 
1245 -hsync +vsync
xrandr --addmode VGA-1 1920x1200_60.00
xrandr --output VGA-1 --mode 1920x1200_60.00

This gave me my usual window and font size, but there are some side issues
(e.g. where icons go when I minimize them).

In any case, I think the problem is upstream of X windows.  I boot to a
console, and the font there was much bigger than usual.  Where is that
controlled?  Any idea how to get this back to normal?  The monitor is set to
an aspect ratio of 16:1.  Resetting the monitor and rebooting did not fix
the problem.

Thanks.

Re: black screen in sid

[David]

On Thu, Dec 1, 2022 at 20:02, Jeremy Hendricks  
wrote:
In my experience, it’s of unheard of for Sid to break from time to 
time. I’d imagine updating in a day or a few might fix it.


On Thu, Dec 1, 2022 at 8:00 PM Michael Thompson 
mailto:kneedragon1...@gmail.com>> wrote:

Dear Debian ~

Please forgive my neglecting to use the correct format for a bug 
report, but ~ let me explain.
I am a 60 year old home Linux tinkerer, a Linux geek. I run Mint + 
Mate as my host and virtualbox, with a dozen guests. One guest is 
Debian sid.
I just ran sudo apt update; sudo apt full-upgrade and got a black 
screen.
I tried booting into fallback / recovery, and I got told the 
X-server had not started.

Tried the old kernel, same deal.
Small frustration ~ re-install.
Chose the aarnet.edu.au <http://aarnet.edu.au/> mirror (I am in 
Brisbane) and booted, login as root, adduser mike sudo.
Edit sources. Change the two lines that mention bullseye to read sid 
- delete everything else.

Reboot.
Black screen.
Try the fallback - black screen.
Try the recovery, ask for startx - same msg.
I THINK your problem lays with the latest revision of the Xserver.
If you would like a screenshot of the output in the tty when X 
wouldn't start, I have a screenshot I can send you. Reply to this 
email.

I hope you find this helpful. Mike
kneedragon1...@gmail.com <mailto:kneedragon1...@gmail.com>


I run SID as standard.
I usually update daily with aptitude which overlays apt.
I have no problems.
Unless I was doing  an upgrade from testing to Sid, I wouldn't use 
`full-upgrade' on the cli, but `safe-upgrade'.

HTH.
Cheers!

Re: black screen in sid

[Jeremy Hendricks]

In my experience, it’s of unheard of for Sid to break from time to time.
I’d imagine updating in a day or a few might fix it.

On Thu, Dec 1, 2022 at 8:00 PM Michael Thompson 
wrote:

> Dear Debian ~
>
> Please forgive my neglecting to use the correct format for a bug report,
> but ~ let me explain.
> I am a 60 year old home Linux tinkerer, a Linux geek. I run Mint + Mate as
> my host and virtualbox, with a dozen guests. One guest is Debian sid.
> I just ran sudo apt update; sudo apt full-upgrade and got a black screen.
> I tried booting into fallback / recovery, and I got told the X-server had
> not started.
> Tried the old kernel, same deal.
> Small frustration ~ re-install.
> Chose the aarnet.edu.au mirror (I am in Brisbane) and booted, login as
> root, adduser mike sudo.
> Edit sources. Change the two lines that mention bullseye to read sid -
> delete everything else.
> Reboot.
> Black screen.
> Try the fallback - black screen.
> Try the recovery, ask for startx - same msg.
> I THINK your problem lays with the latest revision of the Xserver.
> If you would like a screenshot of the output in the tty when X wouldn't
> start, I have a screenshot I can send you. Reply to this email.
> I hope you find this helpful. Mike
> kneedragon1...@gmail.com
>

black screen in sid

[Michael Thompson]

Dear Debian ~

Please forgive my neglecting to use the correct format for a bug report,
but ~ let me explain.
I am a 60 year old home Linux tinkerer, a Linux geek. I run Mint + Mate as
my host and virtualbox, with a dozen guests. One guest is Debian sid.
I just ran sudo apt update; sudo apt full-upgrade and got a black screen.
I tried booting into fallback / recovery, and I got told the X-server had
not started.
Tried the old kernel, same deal.
Small frustration ~ re-install.
Chose the aarnet.edu.au mirror (I am in Brisbane) and booted, login as
root, adduser mike sudo.
Edit sources. Change the two lines that mention bullseye to read sid -
delete everything else.
Reboot.
Black screen.
Try the fallback - black screen.
Try the recovery, ask for startx - same msg.
I THINK your problem lays with the latest revision of the Xserver.
If you would like a screenshot of the output in the tty when X wouldn't
start, I have a screenshot I can send you. Reply to this email.
I hope you find this helpful. Mike
kneedragon1...@gmail.com

Re: After some effort, can't change grub screen resolution

[bridgenash...@gmail.com]

y.com/aqua+vitae) from TheFreeDictionary.com (http://www.thefreedictionary.com)

Sent from Yahoo Mail on Android

Re: Google Chrome can share but Chromium cannot share screen

[Pankaj Jangid]

Corentin Bardet  writes:

> I think you have no other option than using Google Chrome for your
> meetings.

Screen sharing works in Firefox ESR on Wayland. So I still have
options. Just that few features - like blur background etc. doesn't
work in FF.

Re: Google Chrome can share but Chromium cannot share screen

[Steve Litt]

On Sun, 2022-09-11 at 10:26 +0200, Corentin Bardet wrote:
> Hi,
> 
> Le 2022-09-11 07:39, Pankaj Jangid a écrit :
> > For a few work related meetings, I have to use Google Meet. But the
> > screensharing doesn't work in the Chromium installed from stable APT
> > repository. Clicking on the share-screen icon and then selecting any of
> > the three options - Tab, Windows, Entire Screen - shows this error
> > message,
> > 
> > "Your browser can't share your screen"
> > 
> > But if I install and use Google Chrome, then the screen sharing works 
> > in
> > Google Meet.
> 
> That doesn't surprise me much.
> 
> Google removed the majority of its APIs from Chromium : 
> [here](
> https://en.wikipedia.org/wiki/Chromium_(web_browser)#Differences_from_Google_Chrom
> e) 
> and 
> [here](https://www.omgubuntu.co.uk/2021/01/chromium-sync-google-api-removed)
> 
> Maybe screen sharing was a Google thing. Especially screen sharing to 
> Google Meet.
> 
> I think you have no other option than using Google Chrome for your 
> meetings.

O r   u s e   J i t s i ! 

SteveT

Re: Google Chrome can share but Chromium cannot share screen

[David]

On Sun, Sep 11, 2022 at 10:26, Corentin Bardet  
wrote:

Hi,

Le 2022-09-11 07:39, Pankaj Jangid a écrit :

For a few work related meetings, I have to use Google Meet. But the
screensharing doesn't work in the Chromium installed from stable APT
repository. Clicking on the share-screen icon and then selecting any 
of

the three options - Tab, Windows, Entire Screen - shows this error
message,

"Your browser can't share your screen"

But if I install and use Google Chrome, then the screen sharing 
works in

Google Meet.


That doesn't surprise me much.

Google removed the majority of its APIs from Chromium : 
[here](<https://en.wikipedia.org/wiki/Chromium_(web_browser>)#Differences_from_Google_Chrome) 
and 
[here](<https://www.omgubuntu.co.uk/2021/01/chromium-sync-google-api-removed>)


Maybe screen sharing was a Google thing. Especially screen sharing to 
Google Meet.


I think you have no other option than using Google Chrome for your 
meetings.


If that's truly the case, they don't appear to be living up to 
licencing agreement.

Cheers!

Re: Google Chrome can share but Chromium cannot share screen

[Corentin Bardet]

Hi,

Le 2022-09-11 07:39, Pankaj Jangid a écrit :

For a few work related meetings, I have to use Google Meet. But the
screensharing doesn't work in the Chromium installed from stable APT
repository. Clicking on the share-screen icon and then selecting any of
the three options - Tab, Windows, Entire Screen - shows this error
message,

"Your browser can't share your screen"

But if I install and use Google Chrome, then the screen sharing works 
in

Google Meet.


That doesn't surprise me much.

Google removed the majority of its APIs from Chromium : 
[here](https://en.wikipedia.org/wiki/Chromium_(web_browser)#Differences_from_Google_Chrome) 
and 
[here](https://www.omgubuntu.co.uk/2021/01/chromium-sync-google-api-removed)


Maybe screen sharing was a Google thing. Especially screen sharing to 
Google Meet.


I think you have no other option than using Google Chrome for your 
meetings.


Cheers,

Corentin Bardet
coren...@noxnet.eu

Google Chrome can share but Chromium cannot share screen

[Pankaj Jangid]

For a few work related meetings, I have to use Google Meet. But the
screensharing doesn't work in the Chromium installed from stable APT
repository. Clicking on the share-screen icon and then selecting any of
the three options - Tab, Windows, Entire Screen - shows this error
message,

"Your browser can't share your screen"

But if I install and use Google Chrome, then the screen sharing works in
Google Meet.

Re: Hibernation issue [was: Bookworm : graphic glitches all over my screen after upgrade]

[Computer Enthusiastic]

Hello,

> Il giorno 29 ago 2022, alle ore 17:49, rudu  ha scritto:
> 
>  Le 27/08/2022 à 11:42, Computer Enthusiastic a écrit :
>> Hello,
>> 
>>> […]
> 
> Thank you very much, the boot parameters trick worked like a charm.
> Now whatever Kernel I choose to boot, the hibernation process works as 
> expected.
> 
> Rudu

I’m happy I helped you to sort it out.  :-)

Please, if you can, report it to the Debian bug tracking system updating the 
bug report at [1]. 

Thanks.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705

Re: Hibernation issue [was: Bookworm : graphic glitches all over my screen after upgrade]

[rudu]

Le 27/08/2022 à 11:42, Computer Enthusiastic a écrit :

Hello,

Il giorno 26 ago 2022, alle ore 19:31, piorunz  ha 
scritto:


On 26/08/2022 10:18, rudu wrote:


You should be right, but after booting on both 5.10 kernels I found in
my repositories :
ii linux-image-5.10.0-13-amd64  5.10.106-1   amd64 Linux 5.10
for 64-bit PCs (signed)
ii linux-image-5.10.0-16-amd64  5.10.127-1   amd64 Linux 5.10
for 64-bit PCs (signed)

... the hibernation process fails as described above ...

With Linux birdynam 5.7.0-3-amd64 #1 SMP Debian 5.7.17-1 (2020-08-23)
x86_64 GNU/Linux hibernation works as expected.


I suggest you should report this error as soon as


A bug report is already opened [1]. A workaround (using kernel boot 
parameters) and a kernel patch are reported in [1]. Working is in 
progress to let the patch reach upstream kernel [2]. I have 
successfully used both the workaround parameters or the patch and I’m 
currently using a custom Debian kernel with the aforementioned 
patch to solve this bug.


HTH

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705
[2] https://lists.freedesktop.org/archives/nouveau/2022-August/040756.html


Thank you very much, the boot parameters trick worked like a charm.
Now whatever Kernel I choose to boot, the hibernation process works as 
expected.


Rudu

Re: Hibernation issue [was: Bookworm : graphic glitches all over my screen after upgrade]

[Computer Enthusiastic]

Hello,

> Il giorno 26 ago 2022, alle ore 19:31, piorunz  ha scritto:
> 
> On 26/08/2022 10:18, rudu wrote:
> 
>> You should be right, but after booting on both 5.10 kernels I found in
>> my repositories :
>> ii  linux-image-5.10.0-13-amd64  5.10.106-1   amd64 Linux 5.10
>> for 64-bit PCs (signed)
>> ii  linux-image-5.10.0-16-amd64  5.10.127-1   amd64 Linux 5.10
>> for 64-bit PCs (signed)
>> 
>> ... the hibernation process fails as described above ...
>> 
>> With Linux birdynam 5.7.0-3-amd64 #1 SMP Debian 5.7.17-1 (2020-08-23)
>> x86_64 GNU/Linux hibernation works as expected.
> 
> I suggest you should report this error as soon as

A bug report is already opened [1]. A workaround (using kernel boot parameters) 
and a kernel patch are reported in [1]. Working is in progress to let the patch 
reach upstream kernel [2]. I have successfully used both the workaround 
parameters or the patch and I’m currently using a custom Debian kernel with the 
aforementioned patch to solve this bug.

HTH

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705
[2] https://lists.freedesktop.org/archives/nouveau/2022-August/040756.html

Re: Hibernation issue [was: Bookworm : graphic glitches all over my screen after upgrade]

[piorunz]

On 26/08/2022 10:18, rudu wrote:


You should be right, but after booting on both 5.10 kernels I found in
my repositories :
ii  linux-image-5.10.0-13-amd64  5.10.106-1   amd64 Linux 5.10
for 64-bit PCs (signed)
ii  linux-image-5.10.0-16-amd64  5.10.127-1   amd64 Linux 5.10
for 64-bit PCs (signed)

... the hibernation process fails as described above ...

With Linux birdynam 5.7.0-3-amd64 #1 SMP Debian 5.7.17-1 (2020-08-23)
x86_64 GNU/Linux hibernation works as expected.


I suggest you should report this error as soon as possible.

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

Re: Hibernation issue [was: Bookworm : graphic glitches all over my screen after upgrade]

[rudu]

  bthLe 25/08/2022 à 23:51, piorunz a écrit :

On 25/08/2022 09:13, rudu wrote:

Le 24/08/2022 à 22:32, piorunz a écrit :

Looking at your kernel version, why you are running two years old
kernel? Support for this kernel has ended upstream, your system is
vulnerable to security issues.



That's because I experienced hibernation issues from this kernel up.
The screen shuts down ok, but the power never goes off, I have to use
the button.
And next boot is a standard one.
Don't know where to look for a clue here.

Regards
Rudu



That's very sad to hear.
Have you tried to report this to Debian BTS?
How about LTS kernel 5.10? That didn't worked either?

You are on Debian Testing and using older kernel than Debian Stable,
that's very uncommon.


You should be right, but after booting on both 5.10 kernels I found in 
my repositories :
ii  linux-image-5.10.0-13-amd64  5.10.106-1   amd64 Linux 5.10 
for 64-bit PCs (signed)
ii  linux-image-5.10.0-16-amd64  5.10.127-1   amd64 Linux 5.10 
for 64-bit PCs (signed)


... the hibernation process fails as described above ...

With Linux birdynam 5.7.0-3-amd64 #1 SMP Debian 5.7.17-1 (2020-08-23) 
x86_64 GNU/Linux hibernation works as expected.


Rudu

Re: Hibernation issue [was: Bookworm : graphic glitches all over my screen after upgrade]

[piorunz]

On 25/08/2022 09:13, rudu wrote:

Le 24/08/2022 à 22:32, piorunz a écrit :

Looking at your kernel version, why you are running two years old
kernel? Support for this kernel has ended upstream, your system is
vulnerable to security issues.



That's because I experienced hibernation issues from this kernel up.
The screen shuts down ok, but the power never goes off, I have to use
the button.
And next boot is a standard one.
Don't know where to look for a clue here.

Regards
Rudu



That's very sad to hear.
Have you tried to report this to Debian BTS?
How about LTS kernel 5.10? That didn't worked either?

You are on Debian Testing and using older kernel than Debian Stable,
that's very uncommon.

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

Re: Hibernation issue [was: Bookworm : graphic glitches all over my screen after upgrade]

[rudu]

Le 24/08/2022 à 22:32, piorunz a écrit :

Looking at your kernel version, why you are running two years old
kernel? Support for this kernel has ended upstream, your system is
vulnerable to security issues.



That's because I experienced hibernation issues from this kernel up.
The screen shuts down ok, but the power never goes off, I have to use 
the button.

And next boot is a standard one.
Don't know where to look for a clue here.

Regards
Rudu

Re: Bookworm : graphic glitches all over my screen after upgrade

[piorunz]

On 24/08/2022 10:39, rudu wrote:

Then a reboot and ... bingo ! The artefacts were gone, everything back
in order.

So Sven, you must be right as I can see some mesa packages removed or
downgraded in my last move, hope that bug will be resolved soon.

I know it's a bit late, but Piotr asked me for an output, here it is :
$ inxi -G
Graphics:
   Device-1: NVIDIA G96C [GeForce 9400 GT] driver: nouveau v: kernel
   Display: x11 server: X.Org v: 1.20.11 with: Xwayland driver: X:
     loaded: modesetting gpu: nouveau resolution: 1920x1080~60Hz
   OpenGL: renderer: NV96 v: 3.3 Mesa 20.3.5

And for good mesure :
$ uname -a && cat /etc/debian_version
Linux birdynam 5.7.0-3-amd64 #1 SMP Debian 5.7.17-1 (2020-08-23) x86_64
GNU/Linux
bookworm/sid

Thanks again to Piotr and Sven and all the subscribers of this great list
Rudu


Great to hear! I am glad you can enjoy your Debian system again. :)

Looking at your kernel version, why you are running two years old
kernel? Support for this kernel has ended upstream, your system is
vulnerable to security issues.

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

Re: Bookworm : graphic glitches all over my screen after upgrade

[rudu]

Piotr, Sven, Thank you for your help, see below.

Le 23/08/2022 à 20:55, piorunz a écrit :

On 23/08/2022 14:13, rudu wrote:

Hi,

Coming back from holidays, I did a pretty huge upgrade of my Bookworm
system on my aging desktop (2009).
After a reboot, what I could see is best described via this snapshot :
https://wtf.roflcopter.fr/pics/rVcN0HFu/vgQCGy7g.png


Only one thing I can think of is nouveau driver issue.
If I am not mistaken, Bookworm has libdrm-nouveau2 and
xserver-xorg-video-nouveau packages to provide nouveau driver.
Only libdrm-nouveau2 has seen new upstream release landing in bookworm
recently.

See in your apt logs if these packages were part of the upgrade you
undertaken recently? For me, history.log shows upgrade entry on
2022-08-03 (20 days ago): libdrm-nouveau2:amd64 (upgrade from version
2.4.110-1 to version 2.4.112-3).

Also please show output of
inxi -G
command in terminal. Install inxi if you haven't already.

--
With kindest regards, Piotr.


I've been already trying some downgrades, of :
Downgrade: xserver-xorg-video-nouveau:amd64 (1:1.0.17-2, 1:1.0.17-1), 
xserver-xorg-input-evdev:amd64 (1:2.10.6-2+b1, 1:2.10.6-2), 
xserver-xorg-core:amd64 (2:21.1.4-1, 2:1.20.11-1+deb11u1)

Purge: xserver-xephyr:amd64 (2:21.1.4-1)
Downgrade: xserver-xorg:amd64 (1:7.7+23, 1:7.7+22), xserver-common:amd64 
(2:21.1.4-1, 2:1.20.11-1+deb11u1)

... the stable versions of those packages.
But nothing changed.

Then, Piotr drew my attention to this libdrm-nouveau2 :
Downgrade: libdrm-nouveau2:amd64 (2.4.112-3, 2.4.104-1), 
libdrm-nouveau2:i386 (2.4.112-3, 2.4.104-1)

... still no luck.

Looking at its dependencies, I noticed a libdrm2 and libdrm-common 
packages. Their downgrade had some consequences :
Install: libllvm11:amd64 (1:11.1.0-6+b2, automatic), 
kwin-wayland-backend-x11:amd64 (4:5.25.4-2, automatic), 
libdrm-intel1:amd64 (2.4.104-1, automatic)
Downgrade: libglx-mesa0:amd64 (22.2.0~rc2-1, 20.3.5-1), libgbm1:amd64 
(22.2.0~rc2-1, 20.3.5-1), libgl1-mesa-dri:amd64 (22.2.0~rc2-1, 
20.3.5-1), libdrm-common:amd64 (2.4.112-3, 2.4.104-1), xwayland:amd64 
(2:22.1.3-1, 2:1.20.11-1+deb11u1), libglapi-mesa:amd64 (22.2.0~rc2-1, 
20.3.5-1), libdrm-amdgpu1:amd64 (2.4.112-3, 2.4.104-1), 
libdrm-radeon1:amd64 (2.4.112-3, 2.4.104-1), libdrm-radeon1:i386 
(2.4.112-3, 2.4.104-1), libdrm2:amd64 (2.4.112-3, 2.4.104-1), 
libdrm2:i386 (2.4.112-3, 2.4.104-1), libegl-mesa0:amd64 (22.2.0~rc2-1, 
20.3.5-1), libdrm-intel1:i386 (2.4.112-3, 2.4.104-1)
Remove: libxcb-present0:i386 (1.15-1), libglx-mesa0:i386 (22.2.0~rc2-1), 
libglvnd0:i386 (1.4.0-1), libxshmfence1:i386 (1.3-1), libdecor-0-0:i386 
(0.1.0-3), libfltk1.1:i386 (1.1.10-29), libwayland-cursor0:i386 
(1.21.0-1), libxcb-dri2-0:i386 (1.15-1), libxcb-dri3-0:i386 (1.15-1), 
libgbm1:i386 (22.2.0~rc2-1), libwayland-server0:i386 (1.21.0-1), 
libglx0:i386 (1.4.0-1), libdrm-nouveau2:i386 (2.4.104-1), libllvm14:i386 
(1:14.0.6-2), kwin-wayland-backend-drm:amd64 (4:5.25.4-2), libz3-4:i386 
(4.8.12-1+b1), libxcvt0:amd64 (0.1.2-1), libgl1-mesa-dri:i386 
(22.2.0~rc2-1), libxkbcommon0:i386 (1.4.1-1), freeglut3:i386 (2.8.1-6), 
libxcb-glx0:i386 (1.15-1), libwayland-egl1:i386 (1.21.0-1), 
libglapi-mesa:i386 (22.2.0~rc2-1), libsdl2-2.0-0:i386 (2.0.22+dfsg-6), 
libdrm-amdgpu1:i386 (2.4.112-3), libgl1:i386 (1.4.0-1), 
libwayland-client0:i386 (1.21.0-1), libxcb-sync1:i386 (1.15-1), 
libatomic1:i386 (12.1.0-8), libxcb-xfixes0:i386 (1.15-1)


Then a reboot and ... bingo ! The artefacts were gone, everything back 
in order.


So Sven, you must be right as I can see some mesa packages removed or 
downgraded in my last move, hope that bug will be resolved soon.


I know it's a bit late, but Piotr asked me for an output, here it is :
$ inxi -G
Graphics:
  Device-1: NVIDIA G96C [GeForce 9400 GT] driver: nouveau v: kernel
  Display: x11 server: X.Org v: 1.20.11 with: Xwayland driver: X:
    loaded: modesetting gpu: nouveau resolution: 1920x1080~60Hz
  OpenGL: renderer: NV96 v: 3.3 Mesa 20.3.5

And for good mesure :
$ uname -a && cat /etc/debian_version
Linux birdynam 5.7.0-3-amd64 #1 SMP Debian 5.7.17-1 (2020-08-23) x86_64 
GNU/Linux

bookworm/sid

Thanks again to Piotr and Sven and all the subscribers of this great list
Rudu

Re: Bookworm : graphic glitches all over my screen after upgrade

[Sven Joachim]

On 2022-08-23 15:13 +0200, rudu wrote:

> Coming back from holidays, I did a pretty huge upgrade of my Bookworm
> system on my aging desktop (2009).
> After a reboot, what I could see is best described via this snapshot :
> https://wtf.roflcopter.fr/pics/rVcN0HFu/vgQCGy7g.png
>
> What I tried so far :
> - replacing my nouveau driver by a proprietary one, but :
> $ nvidia-detect
> Detected NVIDIA GPUs:
> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G96C
> [GeForce 9400 GT] [10de:0641] (rev a1)
>
> Checking card:  NVIDIA Corporation G96C [GeForce 9400 GT] (rev a1)
> Your card is only supported by the 340 legacy drivers series, which is
> only available up to buster.
>
> - installed the last kernel for testing :
> $ dpkg -l linux-image-* | grep ^ii
> ii  linux-image-5.18.0-4-amd64  5.18.16-1    amd64 Linux 5.18
> for 64-bit PCs (signed)
> ii  linux-image-5.7.0-2-amd64   5.7.10-1 amd64 Linux 5.7
> for 64-bit PCs (signed)
> ii  linux-image-5.7.0-3-amd64   5.7.17-1 amd64 Linux 5.7
> for 64-bit PCs (signed)
> ii  linux-image-amd64   5.18.16-1    amd64 Linux for
> 64-bit PCs (meta-package)
> ... no change.
>
> - reconfigured window display management between lightdm/sddm/gdm3 :
> Curiously, only sddm showed no sign of being affected, until I opened
> a graphic environment (LXDE, XFCE4, Gnome-Xorg/wayland,
> Plasma-Xorg/wayland) where the problem was always back.
>
> - I looked into /var/log/apt/term.log resulting from my last upgrade
>   and tried to find something relevant and I saw this :
> cat /var/log/apt/term.log | grep xserver
> Préparation du dépaquetage de .../38-xserver-common_2%3a21.1.4-1_all.deb ...
> Dépaquetage de xserver-common (2:21.1.4-1) sur (2:21.1.3-2) ...
> Préparation du dépaquetage de
> .../39-xserver-xorg-core_2%3a21.1.4-1_amd64.deb ...
> Dépaquetage de xserver-xorg-core (2:21.1.4-1) sur (2:21.1.3-2+b1) ...
> Préparation du dépaquetage de
> .../359-xserver-xephyr_2%3a21.1.4-1_amd64.deb ...
> Dépaquetage de xserver-xephyr (2:21.1.4-1) sur (2:21.1.3-2+b1) ...
> Paramétrage de xserver-common (2:21.1.4-1) ...
> Paramétrage de xserver-xephyr (2:21.1.4-1) ...
> Paramétrage de xserver-xorg-core (2:21.1.4-1) ...
>
> I don't know what to do or where to look, my system is barely usable
> now and freezes regularly ...

Seems you are experiencing bug #1017499[1], for which no solution
currently exists.  Try downgrading your installed packages from
src:mesa.

Good luck,
  Sven


1. https://bugs.debian.org/1017499

Re: Bookworm : graphic glitches all over my screen after upgrade

[piorunz]

On 23/08/2022 14:13, rudu wrote:

Hi,

Coming back from holidays, I did a pretty huge upgrade of my Bookworm
system on my aging desktop (2009).
After a reboot, what I could see is best described via this snapshot :
https://wtf.roflcopter.fr/pics/rVcN0HFu/vgQCGy7g.png


Only one thing I can think of is nouveau driver issue.
If I am not mistaken, Bookworm has libdrm-nouveau2 and
xserver-xorg-video-nouveau packages to provide nouveau driver.
Only libdrm-nouveau2 has seen new upstream release landing in bookworm
recently.

See in your apt logs if these packages were part of the upgrade you
undertaken recently? For me, history.log shows upgrade entry on
2022-08-03 (20 days ago): libdrm-nouveau2:amd64 (upgrade from version
2.4.110-1 to version 2.4.112-3).

Also please show output of
inxi -G
command in terminal. Install inxi if you haven't already.

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

Bookworm : graphic glitches all over my screen after upgrade

[rudu]

Hi,

Coming back from holidays, I did a pretty huge upgrade of my Bookworm 
system on my aging desktop (2009).

After a reboot, what I could see is best described via this snapshot :
https://wtf.roflcopter.fr/pics/rVcN0HFu/vgQCGy7g.png

What I tried so far :
- replacing my nouveau driver by a proprietary one, but :
$ nvidia-detect
Detected NVIDIA GPUs:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G96C 
[GeForce 9400 GT] [10de:0641] (rev a1)


Checking card:  NVIDIA Corporation G96C [GeForce 9400 GT] (rev a1)
Your card is only supported by the 340 legacy drivers series, which is 
only available up to buster.


- installed the last kernel for testing :
$ dpkg -l linux-image-* | grep ^ii
ii  linux-image-5.18.0-4-amd64  5.18.16-1    amd64 Linux 5.18 
for 64-bit PCs (signed)
ii  linux-image-5.7.0-2-amd64   5.7.10-1 amd64 Linux 5.7 for 
64-bit PCs (signed)
ii  linux-image-5.7.0-3-amd64   5.7.17-1 amd64 Linux 5.7 for 
64-bit PCs (signed)
ii  linux-image-amd64   5.18.16-1    amd64 Linux for 
64-bit PCs (meta-package)

... no change.

- reconfigured window display management between lightdm/sddm/gdm3 :
Curiously, only sddm showed no sign of being affected, until I opened a 
graphic environment (LXDE, XFCE4, Gnome-Xorg/wayland, 
Plasma-Xorg/wayland) where the problem was always back.


- I looked into /var/log/apt/term.log resulting from my last upgrade and 
tried to find something relevant and I saw this :

cat /var/log/apt/term.log | grep xserver
Préparation du dépaquetage de .../38-xserver-common_2%3a21.1.4-1_all.deb ...
Dépaquetage de xserver-common (2:21.1.4-1) sur (2:21.1.3-2) ...
Préparation du dépaquetage de 
.../39-xserver-xorg-core_2%3a21.1.4-1_amd64.deb ...

Dépaquetage de xserver-xorg-core (2:21.1.4-1) sur (2:21.1.3-2+b1) ...
Préparation du dépaquetage de 
.../359-xserver-xephyr_2%3a21.1.4-1_amd64.deb ...

Dépaquetage de xserver-xephyr (2:21.1.4-1) sur (2:21.1.3-2+b1) ...
Paramétrage de xserver-common (2:21.1.4-1) ...
Paramétrage de xserver-xephyr (2:21.1.4-1) ...
Paramétrage de xserver-xorg-core (2:21.1.4-1) ...

I don't know what to do or where to look, my system is barely usable now 
and freezes regularly ...


Any help would be warmly appreciated
Rudu

Re: Debian 11 Cinnamon Lock Screen Issue

[Ajay R]

> https://github.com/mate-desktop/mate-screensaver/issues/231

This helps. Thank you.

Re: Debian 11 Cinnamon Lock Screen Issue

[David Wright]

On Sun 21 Aug 2022 at 14:35:29 (+), Ajay R wrote:
> I am using the Cinnamon desktop environment on Debian 11. All but one thing 
> has been great so far.
> When I wake my laptop from suspension by opening the lid, before the lock 
> screen shows up, I see
> a brief flash of the desktop behind. This is quite concerning. Is this the 
> right place to get help
> for this issue?

I'm afraid that I lock the screen with vlock (in a VC), so I don't
know the answer. There was a somewhat similar thread in May.
Might this help?

https://lists.debian.org/debian-user/2022/05/msg00357.html

https://github.com/mate-desktop/mate-screensaver/issues/231

Cheers,
David.