How do I remotely access the computer in the next room?

[hobie of RMN]

Hi, All -

I need the best way currently available to operate my brother's computer
in the next room through my computer.  I think we're both running Debian
11, the stable version for me, the testing version for him.  I've tried
ssh -X.  It does work but only for a short time, then the connection
crumbles - his computer has often locked up on him and we have no idea
why, so the 'short time' aspect of the -X approach may relate to that.

The point is, he's been away from home for awhile now and we're not sure
when he'll return. Chiefly I'm looking for the most convenient way to keep
an eye on his incoming e-mail for him.  Mostly I use Mutt; he uses
claws-mail exclusively, so I'll need to remotely launch claws-mail and
have it retrieve latest e-mails.

Thanks in advance for any help on this.

--hobie

[HEALED] Re: Something tweaked my Firefox appearance

[hobie of RMN]

> On Thu, 16 Mar 2023 02:49:28 -0400
> "hobie of RMN"  wrote:
>
> Hello hobie,
>
>>I guess I should be looking for a place to adjust settings of the window
>>manager..?
>
> That tends to adjust settings globally.  If other windows haven't
> changed in appearance, then everything else /might/ end up with fonts
> smaller than you would like.
>
> To affect Ff only, you may wish to investigate using userChrome.css;
> This file will be in a directory called chrome, somewhere under the
> ~/.mozilla directory.  There should be an example CSS file there you
> can use as a template.

Thanks, Dan and Brad. :)  I rebooted the machine (not just the desktop)
and everything returned to normal.  Go figure. :)

--hobie

Something tweaked my Firefox appearance

[hobie of RMN]

Current stable Debian; Firefox 91.13.0esr; xfce4; xfwm4.

Two days ago I restarted my GUI when I saw the disk swap file was growing
too large.  On logging back in I found Firefox's appearance was different
and harder to work with.  Menu bar and Bookmarks toolbar have larger fonts
than before, and Firefox's URL window now accommodates less of the text of
the URL.

I guess I should be looking for a place to adjust settings of the window
manager..?  Is that a file on disk or is there a menu choice for this?

--hobie

[SOLVED, sort of] After upgrade to bullseye, tty1-6 not working

[hobie of RMN]

>> Hello Hobie,
>>
>> On 2022-04-20 12:13 UTC+0200, hobie of RMN wrote:
>>> Hi, Folks -
>>
>>> With buster, I had done some tweaking to the boot command line in order
>>> to
>>> have a certain font size come up in the plain text console windows.
> Should I suspect that's still present in grub and is for some reason
> problematic under bullseye?  Any tips, hints, suggestions, wild-eyed
> speculations would be appreciated. :)
>> Wild-eyed speculation: The tweaks are probably still present in
>> /etc/default/grub. Remove them to see if the problems are related.
>
> thanks, Christian and Greg. :)   Here's the 'tweak' that has worked well
> for years, before this upgrade - I'll break it into a few lines but it's
> all one line in /etc/default/grub:
>
> GRUB_CMDLINE_LINUX=
> "video=640x400.
> consoleblank=600 reboot=pci radeon.cik_support=0 amdgpu.cik_support=1"
>
> Changing video=640x400 to video=640x480 overcomes the "Input not support"
> error problem but makes the characters smaller and leaves some screen real
> estate unused -- which is exactly why video=60x400 is what I had
> eventually added to the command line in the first place. :(
>
> Hardware has remained the same.  What does anyone think has changed in the
> upgrade to produce this odd problem?  Is there a DVI module or driver that
> would be a likely suspect?

(sigh) As mentioned, the video=640x400 appears to have caused my initial
problem, and changing it to video=640x480 took care of that - but it's
left me squinting at my console screens because of the smaller font, and
I'd love to find the way to restore the slightly larger font.  However, I
surrender, glad to have fixed the main initial problem. :)

Re: After upgrade to bullseye, tty1-6 not working

[hobie of RMN]

> Hello Hobie,
>
> On 2022-04-20 12:13 UTC+0200, hobie of RMN wrote:
>> Hi, Folks -
>
>> With buster, I had done some tweaking to the boot command line in order to
>> have a certain font size come up in the plain text console windows.
Should I suspect that's still present in grub and is for some reason
problematic under bullseye?  Any tips, hints, suggestions, wild-eyed
speculations would be appreciated. :)
> Wild-eyed speculation: The tweaks are probably still present in
> /etc/default/grub. Remove them to see if the problems are related.

thanks, Christian and Greg. :)   Here's the 'tweak' that has worked well
for years, before this upgrade - I'll break it into a few lines but it's
all one line in /etc/default/grub:

GRUB_CMDLINE_LINUX=
"video=640x400.
consoleblank=600 reboot=pci radeon.cik_support=0 amdgpu.cik_support=1"

Changing video=640x400 to video=640x480 overcomes the "Input not support"
error problem but makes the characters smaller and leaves some screen real
estate unused -- which is exactly why video=60x400 is what I had
eventually added to the command line in the first place. :(

Hardware has remained the same.  What does anyone think has changed in the
upgrade to produce this odd problem?  Is there a DVI module or driver that
would be a likely suspect?

After upgrade to bullseye, tty1-6 not working

[hobie of RMN]

Hi, Folks -

On reboot after upgrading from buster to bullseye, my AOC monitor,
connected via DVI, is showing "Input Not Support" on non-GUI tty1-tty6 -
but, tty7 is successfully running the GUI (xfce4 in my case) and it shows
up fine on that same monitor.

With buster, I had done some tweaking to the boot command line in order to
have a certain font size come up in the plain text console windows. 
Should I suspect that's still present in grub and is for some reason
problematic under bullseye?  Any tips, hints, suggestions, wild-eyed
speculations would be appreciated. :)

--hobie

Creation vs Modification timestamps

[hobie of RMN]

Lately a script that has worked well and as intended for years and years
has begun doing something odd.  When archiving a bunch of flat files,
instead of keeping the creation timestamps on those files, it stamps them
with the date and time of their being moved.

Why that's happening is a separate issue and one that I do need to find
the answer to, but my question today is this:  Is it possible to find the
original creation date-and-time on these files, or is it simply "gone with
the wind" at this point?

--hobie

[SOLVED} Re: "Run fsck manually"..?

[hobie of RMN]

> On Wed, Feb 03, 2021 at 01:41:54AM +, Andy Smith wrote:
>> On Tue, Feb 02, 2021 at 07:13:16PM -0500, hobie of RMN wrote:
>> > He enters "fsck" or "fsck /dev/sda1", and in a short while gets fsck
>> > identifying it's version, and nothing else.
>>
>> There can be issues trying to run fsck on a mounted filesystem. What
>> happens if you do:
>>
>> # touch /forcefsck
>
> Oh, sorry, I missed your mention of (initramfs) prompt. So your
> filesystem is too damaged to allow boot to complete and you won't be
> able to do that "touch /forcefsck" thing.
>
> If fsck is just printing its version it may think it doesn't need to
> be run. You can force it to do a check/repair with "-f", so:
>
> (initramfs) fsck.ext4 -vf /dev/sda1
>
> If it find things that it wants to fix it will ask yuo and you'll
> have to press 'y' each time. If you're certain that you always want
> to answer 'y' then you can ctrl-c that and try again with -y:
>
> (initramfs) fsck.ext4 -yvf /dev/sda1
>
> If you want to see what it would do without it actually doing it you
> can use -n instead of -y.
>
> Cheers,
> Andy

Thanks, Andy and everyone. :)  From the (initramfs) prompt, fsck -y
/dev/sda1 did the job. :) My brother finally realized he'd entered an
extra character originally, causing fsck to fail on his original attempt -
he had entered "./dev/sda1" instead of "/dev/sda1" - so removing that '.'
was part of solving this.  Like so many these days, he spends mos or all
of his time in the GUI rather than at the command line.

--hobie

Re: "Run fsck manually"..?

[hobie of RMN]

> You might have to boot from a recovery CD image, such as a Debian live
> install image, or GParted Live. You can't actually run fsck on a drive
> while said drive is mounted.

Thank, Jeremy.  But - is /dev/sda1 mounted at this point?  Isn't it being
indicated to us that it can't be successfully mounted? (Thinking of the
Busybox appearance and (intramfs) reference.)


> On Tue, 2 Feb 2021 at 19:24, Stefan Monnier 
> wrote:
>
>> >> My brother's Debian system suddenly says on attempt to boot,
>> "/dev/sda1:
>> >> UNEXPECTED INCONSISTENCY:Runfsck manually", and, "inodes that were
>> part
>> of
>> >> a corrupted orphan linked list found."
>> >>
>> >> He enters "fsck" or "fsck /dev/sda1", and in a short while gets fsck
>> >> identifying it's version, and nothing else.  Tha appears to take
>> place
>> >> from (initramfs) and Busybox.  An attempt to reboot just starts the
>> >> problem all over again.
>> >>
>> >> We'd be grateful for help with this.  Thanks.
>> >>
>> > hello,
>> >
>> > fsck -fy /dev/sda1 is probably what you want
>>
>> Then again, after the "UNEXPECTED INCONSISTENCY", the `-f` flag to
>> `fsck` shouldn't be needed.  This is weird.
>>
>>
>> Stefan
>>
>>
>

"Run fsck manually"..?

[hobie of RMN]

My brother's Debian system suddenly says on attempt to boot, "/dev/sda1:
UNEXPECTED INCONSISTENCY:Runfsck manually", and, "inodes that were part of
a corrupted orphan linked list found."

He enters "fsck" or "fsck /dev/sda1", and in a short while gets fsck
identifying it's version, and nothing else.  Tha appears to take place
from (initramfs) and Busybox.  An attempt to reboot just starts the
problem all over again.

We'd be grateful for help with this.  Thanks.

Re: dpkg SquirrelMail on Jessie

[hobie of RMN]

> hobie of RMN  wrote:
>> Restating:  I've installed the *.deb of Squirrelmail 1.4.23 SVN but don['t
>> see where to direct the browser in order to engage with it. Anyone
know...?
> The package should contain a configuration making it available via
http(s)://server.name/squirrelmail
> But how and if this works depends solely on your local server
> configuration. Look into /etc/squirrelmail/apache.conf and where and how
this is included into /etc/apache2 on your system.
> Other than that, without knowing your local setup, no more help can
really be given.
> Please make sure to have version 1.4.23~svn20120406-2+deb8u4 installed,
which was the last security update available.
> But, I must stress again: This version still has known security errors
and if you intent to open this version on Jessie to the internet, the
chances are very high your system will get hacked and compromised.
Grüße,
> Sven.

Thanks, Sven.  Yes, /etc/squirrelmail/apache.conf was the key.  Debian's
arrangement did not make that file known to apache on installation. A soft
link to /etc/apache2 did the trick, and
https://[mailhost.example].com/squirrelmail has it up and running. :)

Yes, squirrelmail_2%3a1.4.23~svn20120406-2+deb8u4_all.deb is what I've
installed.

That said, I'm frequently seeing this error message: "This page request
could not be verified and appears to have expired."  I understand this to
be from the implementation of 'security tokens' and that I can make it go
away by setting $disable_security_tokens = true in config.php, but this
opens possibility for CSRF attacks, I've read.

How serious a problem would that be, and are there other protections I
could put in place that would make up for those tokens?

--hobie

Re: dpkg SquirrelMail on Jessie

[hobie of RMN]

> hobie of RMN  wrote:
>
>> I have a server running Jessie (oldoldstable) that has had
>> Squirrelmail 1.4.2 (installed manually) on it for a very long time.
>> At some point, years ago, SM became confused by a change in
>> charactersets (UTC-8, is it?), leading to erratic dropping of lines of
>> text.  I've just installed SM 1.4.3 from a Debian package - but I
>> don't see where it's to be accessed via browser. (??)  Anyone know...?
>
> Jessie is no longer supported. You should not run any system or
> infrastructure on this Debian release.
>
> Furthermore, squirrelmail is also no longer developed or maintained, I
> strongly advise against using it.
>
> Grüße,
> Sven.

Thank, Sven - true, no doubt. :)  I'm not able to take action on those
core issues at present.  An answer to my question could be of immediate
value.

Restating:  I've installed the *.deb of Squirrelmail 1.4.23 SVN but don['t
see where to direct the browser in order to engage with it. Anyone
know...?

--hobie

dpkg SquirrelMail on Jessie

[hobie of RMN]

I have a server running Jessie (oldoldstable) that has had Squirrelmail
1.4.2 (installed manually) on it for a very long time.  At some point,
years ago, SM became confused by a change in charactersets (UTC-8, is
it?), leading to erratic dropping of lines of text.  I've just installed
SM 1.4.3 from a Debian package - but I don't see where it's to be accessed
via browser. (??)  Anyone know...?

--hobie

Re: Disks renamed after update to 'testing'...?

[hobie of RMN]

> On 2020-08-17 16:42, hobie of RMN wrote:
>> Hi, All -
>>
>> My brother has been issuing "mount /dev/sdb1" prior to backing up some
>> files to a second hard disk.  He lately upgraded to 'testing', and it
>> appears (from result of running df) that what the system now calls
>> /dev/sdb1 is what he has thought of as /dev/sda1, the system '/'
>> partition.
>>
>> Thanks to the UUID= mechanism, his system still boots properly, but
>> 'mount
>> /dev/sdb1' is inappropriate now, could even be the path to madness. :)
>>
>> Two questions, then: (1) What caused this shift of device naming? And
>> (2)
>> How do we fix it?  Is this something that can be changed in the BIOS?
>> But, if so, what caused it to change in the first place?
>>
>> Thanks for your time and attenton.
>
> Please run the following commands as root and post the complete console
> session -- prompt, command issued, and output obtained:
>
>   # cat /etc/fstab
>
>   # mount
>
>
> Please post the complete console session demonstrating the issue with
> mount(8).
>
>
> David
>

Thaks. :)

cat /etc/fstab output includes:
# / was on /dev/sda1 during installation
UUID=3f50ca38-20f3-4a12-880c-a1283ac6e41b /   ext4   
errors=remount-ro 0

'mount' output includes:
/dev/sdb1 on / type ext4 (rw,relatime,errors=remount-ro)

Here's the full output:

root@shelby:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
# / was on /dev/sda1 during installation
UUID=3f50ca38-20f3-4a12-880c-a1283ac6e41b /   ext4   
errors=remount-ro 0   1
# swap was on /dev/sda5 during installation
UUID=ca191c62-2f38-4eae-b4e9-e21337edc198 noneswapsw  
   0   0
/dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0   0
/dev/sr1/media/cdrom1   udf,iso9660 user,noauto 0   0
root@shelby:~#
root@shelby:~# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs
(rw,nosuid,noexec,relatime,size=4023876k,nr_inodes=1005969,mode=755)
devpts on /dev/pts type devpts
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=814860k,mode=755)
/dev/sdb1 on / type ext4 (rw,relatime,errors=remount-ro)
securityfs on /sys/kernel/security type securityfs
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2
(rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup
(rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
cgroup on /sys/fs/cgroup/pids type cgroup
(rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/perf_event type cgroup
(rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/blkio type cgroup
(rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup
(rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/devices type cgroup
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/rdma type cgroup
(rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup
(rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/cpuset type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuset)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs
(rw,relatime,fd=33,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=3406)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
vmware-vmblock on /run/vmblock-fuse type fuse.vmware-vmblock
(rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)
tmpfs on /run/user/0 type tmpfs
(rw,nosuid,nodev,relatime,size=814860k,mode=700)
tmpfs on /run/user/1000 type tmpfs
(rw,nosuid,nodev,relatime,size=814860k,mode=700,uid=1000,gid=1000)

Disks renamed after update to 'testing'...?

[hobie of RMN]

Hi, All -

My brother has been issuing "mount /dev/sdb1" prior to backing up some
files to a second hard disk.  He lately upgraded to 'testing', and it
appears (from result of running df) that what the system now calls
/dev/sdb1 is what he has thought of as /dev/sda1, the system '/'
partition.

Thanks to the UUID= mechanism, his system still boots properly, but 'mount
/dev/sdb1' is inappropriate now, could even be the path to madness. :)

Two questions, then: (1) What caused this shift of device naming? And (2)
How do we fix it?  Is this something that can be changed in the BIOS? 
But, if so, what caused it to change in the first place?

Thanks for your time and attenton.

Re: XFCE4 - How to increase font size on applications?

[hobie of RMN]

> On 14/7/20 10:26 am, hobie of RMN wrote:
>> Hi, Folks -
>>
>> I'm running Linux buster with xce4 desktop.  Some applications come up
>> with font size too small for me to be able to read menu texts, etc.,
>> notably Libre programs and alsamixer, etc.  How can I ge3t larger fonts
>> on
>> individual programs?
>>
>
> Perhaps adjust your display setting to smaller numbers?
>
>
>
> Or is everything else readable?

Some is, some isn't. :)  Firefox, Thunderbird, Leafpad, Notes, Synaptic,
vcl  are readable. ftpsed, alsamixergui, and some others are not.  Liam's
suggestion has made LibreOffice readable, thankfully.

Re: XFCE4 - How to increase font size on applications?

[hobie of RMN]

> On Mon, 13 Jul, 2020 at 20:26:57 -0400, hobie of RMN wrote:
>> Hi, Folks -
>>
>> I'm running Linux buster with xce4 desktop.  Some applications come up
>> with font size too small for me to be able to read menu texts, etc.,
>> notably Libre programs and alsamixer, etc.  How can I ge3t larger fonts
>> on
>> individual programs?
>>
>
> If you install libreoffice-gtk3 then LibreOffice will respect the font
> settings used by XFCE4.

Thanks, Liam - that does help with LibreOffice. :)  alsamixer and probably
other applications still need some kind of adjustment, though. (?)

XFCE4 - How to increase font size on applications?

[hobie of RMN]

Hi, Folks -

I'm running Linux buster with xce4 desktop.  Some applications come up
with font size too small for me to be able to read menu texts, etc.,
notably Libre programs and alsamixer, etc.  How can I ge3t larger fonts on
individual programs?

Re: alternatives to gmail?

[hobie of RMN]

Hi, Karen -

I'm not at all sure this is the solution but I think it's worth considering:

https://safe-mail.net

It offers a few interface designs.  I use the 'Fast' one, which trims away
icons and other graphic niceties.  Since I don't normally use lynx or
elinks, I'm not sure how navigable it is with either of those - I tried
both today and found it awkward, but that may be because of my lack of
familarity with the functioning of those browsers.

I also tried the demo Horde Imp arrangement someone suggested.  My
impression is it works very well with a text browser.  It specifically
offers as a choice a "No Javascript" interface.

--hobie

> Hi folks,
> One of my gmail accounts is no longer accessible, not in links even with
> some JavaScript.  Not in elinks with the same, and most of all, not via
> basic html in lynx.
> I use this account for research, meaning I prefer  a low graphics web
> interface. I am using a screen reader which also for me personally
> makes the low graphics  even more important.
> I am not in a position to host my own email.
> Whatever I choose, I hope to manage forwarding of the presently  existing
> gmail address.  Moving content a plus.
> Anyone have a suggestion for an email service?
> Thanks,
> Karen
>
>

Re: What drivers do I need for a Nvidia geforce GTX 1660 Ti to work?

[hobie of RMN]

> On 2019-08-08 09:06 +0100, Sharon Kimble wrote:
>
>> Yesterday I installed my new graphics card but when I rebooted the
>> system stopped just before the lightdm login box, and just stayed with
>> a cursor blinking at the top left of the screen. I'm assuming that I
>> need new drivers for it, so my question is -
>>
>> What do I need to install to get a - Nvidia geforce GTX 1660 Ti - to
>> work using Debian 10 please?
>
> The nvidia-driver package in non-free should work with it.  There is no
> support by free drivers, you would need at least a Linux 5.2 kernel
> while Debian 10 comes with 4.19.
>
> Cheers,
>Sven

How about GeForce 210...?  Will the nouveau kernel module work for that or
are non-free drivers needed, on Debian 10?

--hobie

Re: Trying to add new video card

[hobie]

Thanks, Felix. P:)

>> My amd64 stable ('buster') system has this on the motherboard:
>
>> AMD Kaveri [Radeon R7 Graphics]
>
>> In the "Psychedelic colors" thread we added this to the kernal
>> commandline:
>
>> radeon.cik_support=0 amdgpu.cik_support=1
>
>> ...which, in the long run, may not have been necessary, but it's still
>> there.
>
> They should be inert with no AMD GPU or APU available.

Whatever's on the motherboard (presumably Kaveri) is still present,
nothing done to tell it to sit idly by.  Here's the current command line:

BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64
root=UUID=c378147d-1aca-4d98-a589-6b47f02e0ef7 ro video=640x400
consoleblank=600 reboot=pci radeon.cik_support=0 amdgpu.cik_support=1
quiet

>> I plugged in an nvidia GeForce 210 card and essentially lost most
>> functional video, resulting in either "no signal" or a message that
>> meant
>> "I can see a signal but somewhere/somehow, it's not supported", sent by
>> the display, depending on which card I connected to the display via
>> either VGA or DVI cable.
>
>> What am I missing?  What do I need to do in order to make use of the
>> nvidia GeForce card?
>
> Is there some leftover manual Kaveri configuration via xrandr, kernel
> cmdline or /etc/X11/xorg.con*? I would expect it to work perfectly
> automagically, like mine:

Here's mine (without the nvidia card; if that card were in place, system
boot would not get far enough for me to read and reply to your post):

inxi -GxxS
System:
  Host: saphira Kernel: 4.19.0-5-amd64 x86_64 bits: 64 compiler: gcc
  v: 8.3.0 Desktop: Xfce 4.12.4 tk: Gtk 2.24.32 wm: xfwm4 dm: LightDM
  Distro: Debian GNU/Linux 10 (buster)
Graphics:
  Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASUSTeK driver: amdgpu
  v: kernel bus ID: 00:01.0 chip ID: 1002:130f
  Display: x11 server: X.Org 1.20.4 driver: amdgpu,ati
  unloaded: fbdev,modesetting,vesa resolution: 1600x900~60Hz
  OpenGL: renderer: AMD KAVERI (DRM 3.27.0 4.19.0-5-amd64 LLVM 7.0.1)
  v: 4.5 Mesa 18.3.6 direct render: Yes

xrandr | egrep 'onnect|creen|\*' | grep -v disconn | sort -r
Screen 0: minimum 320 x 200, current 1600 x 900, maximum 16384 x 16384
DVI-D-0 connected 1600x900+0+0 (normal left inverted right x axis y axis)
443mm x 249mm
   1600x900  60.00*+

Grub:
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX="video=640x400 consoleblank=600 reboot=pci
radeon.cik_support=0 amdgpu.cik_support=1"

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE=640x480
GRUB_GFXPAYLOAD_LINUX=keep

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"


> Are there (EE) lines in /var/log/Xorg.0.log or
> ~/.local/share/xorg/Xorg.0.log?

None, presently. with the  nvidia card having been removed for now, to
make the computer at all usable - but as mentioned, I'm not sure the boot
process even reaches the point of launching an xorg server; messages I've
been seeing are at the console.

>  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
>
> Felix Miata  ***  http://fm.no-ip.com/

I was a big OS/2 fan, felt most unhappy when IBM chose not to support
non-commercial users any longer - but then that's how we've come to be
here together on this list, so ... :)

--hobie

Trying to add new video card

[hobie]

Hi, Folks -

My amd64 stable ('buster') system has this on the motherboard:

AMD Kaveri [Radeon R7 Graphics]

In the "Psychedelic colors" thread we added this to the kernal commandline:

radeon.cik_support=0 amdgpu.cik_support=1

...which, in the long run, may not have been necessary, but it's still there.

I plugged in an nvidia GeForce 210 card and essentially lost most
functional video, resulting in either "no signal" or a message that meant
"I can see a signal but somewhere/somehow, it's not supported", sent by
the display, depending on which card I connected to the display via either
VGA or DVI cable.

What am I missing?  What do I need to do in order to make use of the
nvidia GeForce card?

Re: Psychedelic GUI after stable update to buster

[hobie]

> ho...@rumormillnews.com composed on 2019-07-21 20:13 (UTC-0400):
>
>> my console is no longer 80x25, the way I want it; it's something much
>> smaller,
>> pretty much impossible for me to read.
>
> At 1600x900 you're seeing 200x56 with the standard 16x8 font.
>
>> Many thanks, Etienne, Alexander, Felix, Carl, Cindy Sue, and even bw,
>> for
>> the ideas, brainstorms, and general patience and for walking with me on
>> this rather weird journey. :)  If somehow we can get my 80x25 console
>> back, I think we could declare total victory on this one.
>
> Add to cmdline:
>
>   video=640x400
>
> I usually use video=1440x900 to produce 180x56.
> --

Thanks, Felix. :) It works, and I could get used to it. :)  Yet it's not
the same thing that was there before, with 'nomodeset' in the command
line.  It now takes up all the display real estate, stretching from
side-to-side, where before there were margins on either side.  I'm
guessing 'nomodeset' leads to essentially a VGA display, while
video=640x400 leads to a graphic display that's similar to the VGA one...?
 I made a few tries at using the 'vga=' parameter talked about in docs on
the Web but I get the impression it's no longer used. (?)

As I said, I could get used to this and live contentedly with it. :)  But
it seems odd not to be able easily to regain the console display I was so
used to for so many years.

--hobie

Re: Psychedelic GUI after stable update to buster

[hobie]

ndy Sue, and even bw, for
the ideas, brainstorms, and general patience and for walking with me on
this rather weird journey. :)  If somehow we can get my 80x25 console
back, I think we could declare total victory on this one.

--hobie

Re: Psychedelic GUI after stable update to buster

[hobie]

> hobie, on 2019-07-20 :
>> Thanks. :)  I have a faint memory of inserting 'nomodeset' long years
>> ago
>> in the interest of keeping my console screen at 80x25.
>>
>> cat /proc/cmdline
>> BOOT_IMAGE=/boot/vmlinuz-[...] root=UUID=[...] ro nomodeset reboot=pci
>> quiet
>  There it is:   ^
>
> I'm not sure about the "reboot=pci" but you might want to remove
> "nomodeset" from your GRUB_CMDLINE_LINUX in /etc/default/grub,
> then `sudo update-grub`.
>
> Otherwise said, in details:
>
>> Contents of /etc/default/grub:
>>
>> GRUB_DEFAULT=0
>> GRUB_TIMEOUT=5
>> GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
>> GRUB_CMDLINE_LINUX_DEFAULT="quiet"
>> GRUB_CMDLINE_LINUX="nomodeset reboot=pci"
> Remove this:  ^~
>
> [...]
>> # The resolution used on graphical terminal
>> # note that you can use only modes which your graphic card supports via
>> VBE
>> # you can see them in real GRUB with the command `vbeinfo'
>> #GRUB_GFXMODE=640x480
>   ^
> And you might also want to uncomment that and introduce the
> variable GRUB_GFXPAYLOAD_LINUX=keep to keep your Linux console
> down to 80×25 characters, so the paragraph would become:
>
>   # The resolution used on graphical terminal
>   # note that you can use only modes which your graphic card supports via
> VBE
>   # you can see them in real GRUB with the command `vbeinfo'
>   GRUB_GFXMODE=640x480
>   GRUB_GFXPAYLOAD_LINUX=keep
>
> Not every graphical driver take this properly in account, but it
> should be okay with raedon and amdgpu.
>
> Once this is done, run the following command, and while it runs,
> you should see your various kernels being listed.  This will
> update the command lines at boot time:
>
>   $ sudo update-grub
>
> See how things evolve after issuing a reboot.
>
> Kind Regards,
> --
> Étienne Mollier 
>5AB1 4EDF 63BB CCFF 8B54 2FA9 59DA 56FE FFF3 882D

Thanks. :)  Result: no observable change.  Thankfully, my console's still
at 80x25.  But the shift to psychedelic colors is still there, too.

What the heck is this all about...??

--hobie

Re: Psychedelic GUI after stable update to buster

[hobie]

> Hi,
>
> hobie, on 2019-07-19 :
>> dpkg -l | grep -iE 'amd-graphics|amdgpu|\|fglrx|radeon'
>> ii  firmware-amd-graphics [...]
>> ii  libdrm-amdgpu1:amd64  [...]
>> ii  libdrm-radeon1:amd64  [...]
>> ii  radeontop [...]
>> ii  xserver-xorg-video-amdgpu [...]
>> ii  xserver-xorg-video-ati[...]
>> ii  xserver-xorg-video-mach64 [...]
>> ii  xserver-xorg-video-r128   [...]
>> ii  xserver-xorg-video-radeon [...]
>
> Well, there seem to be everything we need here, even a bit more.
>
>> dmesg | grep -iE 'amd-graphics|amdgpu|\|fglrx|radeon'
>> [0.340065] smpboot: CPU0: AMD A10-7860K Radeon R7, 12 Compute Cores
>> 4C+8G (family: 0x15, model: 0x38, stepping: 0x1)
>> [1.927704] [drm] VGACON disable radeon kernel modesetting.
>> [1.927756] [drm:radeon_init [radeon]] *ERROR* No UMS support in
>> radeon module!
>> [2.085794] [drm:amdgpu_init [amdgpu]] *ERROR* VGACON disables amdgpu
>> kernel modesetting.
>> [   10.423460] [drm] VGACON disable radeon kernel modesetting.
>> [   10.423512] [drm:radeon_init [radeon]] *ERROR* No UMS support in
>> radeon module!
>> [   10.859252] [drm:amdgpu_init [amdgpu]] *ERROR* VGACON disables amdgpu
>> kernel modesetting.
>
> Now, this is interesting!  While browsing the web independently
> on the two error messages "VGACON disables amdgpu kernel
> modesetting" and "No UMS support in radeon module!", in both
> case the culprit was seemingly Kernel ModeSetting (KMS) being
> disabled :
>
>   
> https://unix.stackexchange.com/questions/273471/how-to-solve-drmradeon-init-radeon-error-no-ums-support-in-radeon-module
>   https://bbs.archlinux.org/viewtopic.php?id=166037
>   
> https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/884333-vgacon-disables-amdgpu-kernel-modesetting
>
> This confirms the statement from Alexander V. Makartsev:
>> Kernel mode setting (modeset) is often required to be enabled
>> with recent kernels. "-1" usually means "auto".
>
> It looks to me that you still have something somewhere, perhaps
> not in /etc/modprobe.d since you cleaned that directory up, but
> maybe lurking in some place else, maybe like /etc/default/grub,
> which might still disable KMS.  Which command line is currently
> applied ?
>
>   $ cat /proc/cmdline
>
> Are there particular settings applied to Grub, in case it
> affects boot environment?
>
>   $ cat /etc/default/grub
>
> I suppose that once the question of KMS is cleared, it will be
> possible to go further with other good advices given previously.

Thanks. :)  I have a faint memory of inserting 'nomodeset' long years ago
in the interest of keeping my console screen at 80x25.

cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64
root=UUID=c378147d-1aca-4d98-a589-6b47f02e0ef7 ro nomodeset reboot=pci
quiet


Contents of /etc/default/grub:

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX="nomodeset reboot=pci"

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

--hobie

Re: Psychedelic GUI after stable update to buster

[hobie]

> hobie, on 2019-07-17:
>> I did the edit you suggested - changing the *.si to *.cik on that
second
>> readeon reference - but can't tell if anything was affected by it.
Psychedelic colors still return on leaving the desktop and coming back
to
>> it, and output of inxi -Gxxxz also appears the same:
>> Graphics:
>>   Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASUSTeK
>>   driver: N/A bus ID: 00:01.0 chip ID: 1002:130f
>>   Display: x11 server: X.Org 1.20.4 driver: ati,vesa
>>   unloaded: fbdev,modesetting,radeon resolution: 1600x900~N/A
>>   OpenGL: renderer: llvmpipe (LLVM 7.0 128 bits)
>>   v: 3.3 Mesa 18.3.6 compat-v: 3.1 direct render: Yes
>> Also, I've moved all files from /etc/modprobe.d to a backup directory;
their absence does not appear to have made any difference, either.
> Good Day,
> It seems that some more information is needed to have a clue
> about what is going on with that driver loading.  Would it be
> possible to run the following commands and publish the result?
>   $ dpkg -l | grep -iE 'amd-graphics|amdgpu|\|fglrx|radeon' $ sudo
dmesg | grep -iE 'amd-graphics|amdgpu|\|fglrx|radeon'

Thanks, Etienne. :)  Here's the output:

dpkg -l | grep -iE 'amd-graphics|amdgpu|\|fglrx|radeon'
ii  firmware-amd-graphics   20190114-1
 all  Binary firmware for AMD/ATI
graphics chips
ii  libdrm-amdgpu1:amd642.4.97-1
 amd64Userspace interface to
amdgpu-specific kernel DRM services -- runtime
ii  libdrm-radeon1:amd642.4.97-1
 amd64Userspace interface to
radeon-specific kernel DRM services -- runtime
ii  radeontop   1.1-2
 amd64Utility to show Radeon GPU
utilization
ii  xserver-xorg-video-amdgpu
18.1.99+git20190207-1   amd64X.Org X server --
AMDGPU display driver
ii  xserver-xorg-video-ati  1:19.0.1-1
 amd64X.Org X server -- AMD/ATI
display driver wrapper
ii  xserver-xorg-video-mach64   6.9.6-1
 amd64X.Org X server -- ATI Mach64
display driver
ii  xserver-xorg-video-r128 6.12.0-1
 amd64X.Org X server -- ATI r128
display driver
ii  xserver-xorg-video-radeon   1:19.0.1-1
 amd64X.Org X server -- AMD/ATI
Radeon display driver

- - -

dmesg | grep -iE 'amd-graphics|amdgpu|\|fglrx|radeon'
[0.340065] smpboot: CPU0: AMD A10-7860K Radeon R7, 12 Compute Cores
4C+8G (family: 0x15, model: 0x38, stepping: 0x1)
[1.927704] [drm] VGACON disable radeon kernel modesetting.
[1.927756] [drm:radeon_init [radeon]] *ERROR* No UMS support in radeon
module!
[2.085794] [drm:amdgpu_init [amdgpu]] *ERROR* VGACON disables amdgpu
kernel modesetting.
[   10.423460] [drm] VGACON disable radeon kernel modesetting.
[   10.423512] [drm:radeon_init [radeon]] *ERROR* No UMS support in radeon
module!
[   10.859252] [drm:amdgpu_init [amdgpu]] *ERROR* VGACON disables amdgpu
kernel modesetting.

Re: Psychedelic GUI after stable update to buster

[hobie]

> On 14.07.2019 12:02, ho...@rumormillnews.com wrote:
>>> On 14.07.2019 4:20, Felix Miata wrote:
>>>> ho...@rumormillnews.com composed on 2019-07-13 18:07 (UTC-0400):
>>>>
>>>>> Thanks for the tip.  Looks like a lot of information here but I don't
>>>>> really understand it.  Xorg seems to have unloaded the radeon
>>>>> driver...?
>>>>> Graphics:  Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASUSTeK
>>>>> driver: N/A
>>>>>bus ID: 00:01.0 chip ID: 1002:130f
>>>>>Display: x11 server: X.Org 1.20.4 driver: ati,vesa
>>>>>unloaded: fbdev,modesetting,radeon resolution:
>>>>> 1600x900~N/A
>>>>>OpenGL: renderer: llvmpipe (LLVM 7.0 128 bits) v: 3.3 Mesa
>>>>> 18.3.6
>>>>>compat-v: 3.1 direct render: Yes
>>>>> Where would I find "AMDGPU" and how would I get Xorg to use it?
>>>> These should cover it:
>>>> apt purge xserver-xorg-video-ati xserver-xorg-video-radeon
>>>> apt install xserver-xorg-video-amdgpu firmware-amd-graphics
>>> To install "firmware-amd-graphics" package is a good suggestion.
>>> But chances are high that removal of *-ati and *-radeon packages will
>>> also remove Desktop Environment, because those packages are part of
>>> "xserver-xorg-video-all" package.
>>> I'd suggest a less radical approach and simply "tell" the system what
>>> driver to use via modprobe config files. [1]
>> Thanks. :)  I find old files in /etc/modprobe.d:
>>
>> -rw-r--r-- 1 root root  154 Nov 29  2016 amd64-microcode-blacklist.conf
>> -rw-r--r-- 1 root root   23 Apr 28  2011 i915-kms.conf
>> -rw-r--r-- 1 root root  154 May 15  2017 intel-microcode-blacklist.conf
>> -rw-r--r-- 1 root root   51 May 10  2014 modesetting.conf
>> -rw-r--r-- 1 root root  292 Aug  3  2012 nvidia-kernel-common.conf
>> -rw-r--r-- 1 root root  119 Nov 12  2013 oss-compat.conf
>> -rw-r--r-- 1 root root   27 Jan 19  2014 radeon-kms.conf
>>
>> ...I find radeon-kms.conf contains: "options radeon modeset=-1".  Is
>> that
>> likely where my problem, or part of my problem, is coming from?
>>
>>
> Kernel mode setting (modeset) is often required to be enabled with
> recent kernels. "-1" usually means "auto".
> "radeon-kms.conf" is not part of any package in stretch, so I assume it
> was manually created or a leftovers of some sort from previous system
> upgrades.
>
> The safest approach to test if switching to "amdgpu" driver will help,
> would be adding kernel module parameters at boot time.
> Press "e" to edit grub menu entry and add parameters to "linux" line
> after "quiet" parameter:
>
> amdgpu.si_support=1 amdgpu.cik_support=1 radeon.si_support=0
> radeon.si_support=0
>
> and continue to boot your system by pressing F10.

I did the edit you suggested - changing the *.si to *.cik on that second
readeon reference - but can't tell if anything was affected by it. 
Psychedelic colors still return on leaving the desktop and coming back to
it, and output of inxi -Gxxxz also appears the same:

Graphics:
  Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASUSTeK
  driver: N/A bus ID: 00:01.0 chip ID: 1002:130f
  Display: x11 server: X.Org 1.20.4 driver: ati,vesa
  unloaded: fbdev,modesetting,radeon resolution: 1600x900~N/A
  OpenGL: renderer: llvmpipe (LLVM 7.0 128 bits)
  v: 3.3 Mesa 18.3.6 compat-v: 3.1 direct render: Yes

Also, I've moved all files from /etc/modprobe.d to a backup directory;
their absence does not appear to have made any difference, either.

--hobie

Re: Psychedelic GUI after stable update to buster

[hobie]

> On 14.07.2019 4:20, Felix Miata wrote:
>> ho...@rumormillnews.com composed on 2019-07-13 18:07 (UTC-0400):
>>
>>> Thanks for the tip.  Looks like a lot of information here but I don't
>>> really understand it.  Xorg seems to have unloaded the radeon
>>> driver...?
>>> Graphics:  Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASUSTeK
>>> driver: N/A
>>>bus ID: 00:01.0 chip ID: 1002:130f
>>>Display: x11 server: X.Org 1.20.4 driver: ati,vesa
>>>unloaded: fbdev,modesetting,radeon resolution: 1600x900~N/A
>>>OpenGL: renderer: llvmpipe (LLVM 7.0 128 bits) v: 3.3 Mesa
>>> 18.3.6
>>>compat-v: 3.1 direct render: Yes
>>> Where would I find "AMDGPU" and how would I get Xorg to use it?
>> These should cover it:
>> apt purge xserver-xorg-video-ati xserver-xorg-video-radeon
>> apt install xserver-xorg-video-amdgpu firmware-amd-graphics
> To install "firmware-amd-graphics" package is a good suggestion.
> But chances are high that removal of *-ati and *-radeon packages will
> also remove Desktop Environment, because those packages are part of
> "xserver-xorg-video-all" package.
> I'd suggest a less radical approach and simply "tell" the system what
> driver to use via modprobe config files. [1]

Thanks. :)  I find old files in /etc/modprobe.d:

-rw-r--r-- 1 root root  154 Nov 29  2016 amd64-microcode-blacklist.conf
-rw-r--r-- 1 root root   23 Apr 28  2011 i915-kms.conf
-rw-r--r-- 1 root root  154 May 15  2017 intel-microcode-blacklist.conf
-rw-r--r-- 1 root root   51 May 10  2014 modesetting.conf
-rw-r--r-- 1 root root  292 Aug  3  2012 nvidia-kernel-common.conf
-rw-r--r-- 1 root root  119 Nov 12  2013 oss-compat.conf
-rw-r--r-- 1 root root   27 Jan 19  2014 radeon-kms.conf

...I find radeon-kms.conf contains: "options radeon modeset=-1".  Is that
likely where my problem, or part of my problem, is coming from?

Re: Psychedelic GUI after stable update to buster

[hobie]

>> >>>
>> >> Whoa!  I tried to take screenshots so folks could see what I've
>> >> been trying to describe. Shot of normal screen turns out as
>> >> expected.  Shot of
>> >> psychedelic screen turns out ... identical to shot of normal
>> >> screen!!! In
>> >> other words, what's present in graphic memory space is not the
>> >> same as what's being transmitted to my display/monitor,
>> >> sometimes.  Where's Rod Serling when we need him...? :)
>> >>
>> >>
>> > What display/monitor do you use? Do you connect it using HDMI cable?
>> > I remember another list user was asking same question with identical
>> > symptoms sometime ago.
>> >
>> > --
>> > With kindest regards, Alexander.
>> >
>> Thanks -- the brand is AOC, connected via VGA cable, there's a DVI
>> port on the card but no HDMI one.  (If I plug an HDMI converter in
>> via USB, would that work?)
>>
>
> It should, but the DVI from a computer ought to work into an HDMI
> monitor, though of course it needs an adaptor plug. I've done that
> before.
>
> This sounds like a graphics driver problem, so the DVI may also be
> affected, but maybe not. The colour encoding is very different from VGA.
>
> --
> Joe

I found a DVI cable - turns out the display / monitor has a DVI connection
but not an HDMI one - and hooked it up.  Again, no joy - so I guess we've
narrowed the problem down to the driver...?

Re: Psychedelic GUI after stable update to buster

[hobie]

> On Sb, 13 iul 19, 04:14:52, ho...@rumormillnews.com wrote:
>> >
>> Thanks -- the brand is AOC, connected via VGA cable
>
> I've seen such interesting effects when a VGA cable was not connected
> properly.
>
> You might want to check the cable and connection at both ends.
>
> Kind regards,
> Andrei
> --
> http://wiki.debian.org/FAQsFromDebianUser
>

Thanks - I recall that situation, too, from earlier days. :)  VGA cable is
tightly in place at both ends.  It's curious that this weirdness happened
immediately following the move of 'buster' to 'stable'.

Re: Psychedelic GUI after stable update to buster

[hobie]

> On 13.07.2019 13:14, ho...@rumormillnews.com wrote:
>>> On 13.07.2019 12:44, ho...@rumormillnews.com wrote:
> On Fri, 12 Jul 2019 20:22:55 -0400
> ho...@rumormillnews.com wrote:
>
>>> On Fri, 12 Jul 2019 17:52:43 -0400
>>> ho...@rumormillnews.com wrote:
>>>
 Following recent 'buster' move to 'stable' I got wild psychedelic
 colors
 on my XFCE desktop, making it nearly impossible to read anything
 on-screen.

 Normally I'd have display set for 1024x768.  I've found I can get
 normal
 color on the GUI if I switch to 1600x900.  However, even then, if
 I
 switch
 to console (F1-F6) or if the screensaver comes on, on return the
 psychedelic colors are back.  If I log out / log in to the
 desktop,
 normal
 colors return with the 1600x900 setting only.

 AMD A10-7860K Radeon R7.  ASUSTEK A68HM-K motherboard.
 firmware-linux-free and firmware-linux-nonfree are installed.

 Is this a bug?  Is there a fix? I'd like to get my normal colors
 and
 normal resolution back.  Thanks in advance for any help.

>>> Try a different theme. The switch from GTK-2 to GTK-3 results in a
>>> mess
>>> if the wrong theme is used.
>>>
>> Thanks. :)  Using GTK-ChTheme (which says it's for GTK+ 2, but I
>> don't
>> see
>> a similar utility for GTK+ 3) I switched to Xfce 4.4 but got no
>> improvement.  Should I be approaching this theme change some other
>> way?
>>
> You have the right idea, however, perhaps try adwaita, which is a
> GTK-3
> specific theme.
>
 Whoa!  I tried to take screenshots so folks could see what I've been
 trying to describe. Shot of normal screen turns out as expected.  Shot
 of
 psychedelic screen turns out ... identical to shot of normal screen!!!
 In
 other words, what's present in graphic memory space is not the same as
 what's being transmitted to my display/monitor, sometimes.  Where's
 Rod
 Serling when we need him...? :)


>>> What display/monitor do you use? Do you connect it using HDMI cable?
>>> I remember another list user was asking same question with identical
>>> symptoms sometime ago.
>>>
>>> --
>>> With kindest regards, Alexander.
>>>
>> Thanks -- the brand is AOC, connected via VGA cable, there's a DVI port
>> on
>> the card but no HDMI one.  (If I plug an HDMI converter in via USB,
>> would
>> that work?)
>>
> This is the original thread I was talking about. [1]
> See if there are any pointers that could resolve your issue.
>
> Personally, I don't have much experience with AMD graphics (which is
> sadly notorious for lacking good support on Linux), but
> I would try to use different AMD drivers (use "AMDGPU" instead of
> "radeon" or vice versa).
> You can check what driver you currently using with this command:
>     $ inxi -Gxxxz
>
> [1] https://lists.debian.org/debian-user/2017/12/msg00203.html
>
> --
> With kindest regards, Alexander.

Thanks for the tip.  Looks like a lot of information here but I don't
really understand it.  Xorg seems to have unloaded the radeon driver...?

Graphics:  Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASUSTeK
driver: N/A
   bus ID: 00:01.0 chip ID: 1002:130f
   Display: x11 server: X.Org 1.20.4 driver: ati,vesa
   unloaded: fbdev,modesetting,radeon resolution: 1600x900~N/A
   OpenGL: renderer: llvmpipe (LLVM 7.0 128 bits) v: 3.3 Mesa 18.3.6
   compat-v: 3.1 direct render: Yes

Where would I find "AMDGPU" and how would I get Xorg to use it?

Re: Psychedelic GUI after stable update to buster

[hobie]

> On 13.07.2019 12:44, ho...@rumormillnews.com wrote:
>>> On Fri, 12 Jul 2019 20:22:55 -0400
>>> ho...@rumormillnews.com wrote:
>>>
> On Fri, 12 Jul 2019 17:52:43 -0400
> ho...@rumormillnews.com wrote:
>
>> Following recent 'buster' move to 'stable' I got wild psychedelic
>> colors
>> on my XFCE desktop, making it nearly impossible to read anything
>> on-screen.
>>
>> Normally I'd have display set for 1024x768.  I've found I can get
>> normal
>> color on the GUI if I switch to 1600x900.  However, even then, if I
>> switch
>> to console (F1-F6) or if the screensaver comes on, on return the
>> psychedelic colors are back.  If I log out / log in to the desktop,
>> normal
>> colors return with the 1600x900 setting only.
>>
>> AMD A10-7860K Radeon R7.  ASUSTEK A68HM-K motherboard.
>> firmware-linux-free and firmware-linux-nonfree are installed.
>>
>> Is this a bug?  Is there a fix? I'd like to get my normal colors and
>> normal resolution back.  Thanks in advance for any help.
>>
>
> Try a different theme. The switch from GTK-2 to GTK-3 results in a
> mess
> if the wrong theme is used.
>
 Thanks. :)  Using GTK-ChTheme (which says it's for GTK+ 2, but I don't
 see
 a similar utility for GTK+ 3) I switched to Xfce 4.4 but got no
 improvement.  Should I be approaching this theme change some other
 way?

>>> You have the right idea, however, perhaps try adwaita, which is a GTK-3
>>> specific theme.
>>>
>> Whoa!  I tried to take screenshots so folks could see what I've been
>> trying to describe. Shot of normal screen turns out as expected.  Shot
>> of
>> psychedelic screen turns out ... identical to shot of normal screen!!!
>> In
>> other words, what's present in graphic memory space is not the same as
>> what's being transmitted to my display/monitor, sometimes.  Where's Rod
>> Serling when we need him...? :)
>>
>>
> What display/monitor do you use? Do you connect it using HDMI cable?
> I remember another list user was asking same question with identical
> symptoms sometime ago.
>
> --
> With kindest regards, Alexander.
>
Thanks -- the brand is AOC, connected via VGA cable, there's a DVI port on
the card but no HDMI one.  (If I plug an HDMI converter in via USB, would
that work?)

Re: Psychedelic GUI after stable update to buster

[hobie]

> On Fri, 12 Jul 2019 20:22:55 -0400
> ho...@rumormillnews.com wrote:
>
>>> On Fri, 12 Jul 2019 17:52:43 -0400
>>> ho...@rumormillnews.com wrote:
>>>
Following recent 'buster' move to 'stable' I got wild psychedelic
 colors
on my XFCE desktop, making it nearly impossible to read anything
on-screen.

Normally I'd have display set for 1024x768.  I've found I can get
 normal
color on the GUI if I switch to 1600x900.  However, even then, if I
 switch
to console (F1-F6) or if the screensaver comes on, on return the
psychedelic colors are back.  If I log out / log in to the desktop,
 normal
colors return with the 1600x900 setting only.

AMD A10-7860K Radeon R7.  ASUSTEK A68HM-K motherboard.
firmware-linux-free and firmware-linux-nonfree are installed.

Is this a bug?  Is there a fix? I'd like to get my normal colors and
normal resolution back.  Thanks in advance for any help.

>>>
>>>
>>> Try a different theme. The switch from GTK-2 to GTK-3 results in a mess
>>> if the wrong theme is used.
>>>
>>
>>Thanks. :)  Using GTK-ChTheme (which says it's for GTK+ 2, but I don't
>> see
>>a similar utility for GTK+ 3) I switched to Xfce 4.4 but got no
>>improvement.  Should I be approaching this theme change some other way?
>>
>
> You have the right idea, however, perhaps try adwaita, which is a GTK-3
> specific theme.
>

Whoa!  I tried to take screenshots so folks could see what I've been
trying to describe. Shot of normal screen turns out as expected.  Shot of
psychedelic screen turns out ... identical to shot of normal screen!!!  In
other words, what's present in graphic memory space is not the same as
what's being transmitted to my display/monitor, sometimes.  Where's Rod
Serling when we need him...? :)

Re: Psychedelic GUI after stable update to buster

[hobie]

> On Fri, 12 Jul 2019 20:22:55 -0400
> ho...@rumormillnews.com wrote:
>
>>> On Fri, 12 Jul 2019 17:52:43 -0400
>>> ho...@rumormillnews.com wrote:
>>>
Following recent 'buster' move to 'stable' I got wild psychedelic
 colors
on my XFCE desktop, making it nearly impossible to read anything
on-screen.

Normally I'd have display set for 1024x768.  I've found I can get
 normal
color on the GUI if I switch to 1600x900.  However, even then, if I
 switch
to console (F1-F6) or if the screensaver comes on, on return the
psychedelic colors are back.  If I log out / log in to the desktop,
 normal
colors return with the 1600x900 setting only.

AMD A10-7860K Radeon R7.  ASUSTEK A68HM-K motherboard.
firmware-linux-free and firmware-linux-nonfree are installed.

Is this a bug?  Is there a fix? I'd like to get my normal colors and
normal resolution back.  Thanks in advance for any help.

>>>
>>>
>>> Try a different theme. The switch from GTK-2 to GTK-3 results in a mess
>>> if the wrong theme is used.
>>>
>>
>>Thanks. :)  Using GTK-ChTheme (which says it's for GTK+ 2, but I don't
>> see
>>a similar utility for GTK+ 3) I switched to Xfce 4.4 but got no
>>improvement.  Should I be approaching this theme change some other way?
>>
>
> You have the right idea, however, perhaps try adwaita, which is a GTK-3
> specific theme.
>
Thanks, Charles - I switched to adwaita, but no joy.  Perhaps we're on the
wrong track?  All is well; I switch to console and return or screensaver
blanks the screen; and when the GUI screen is redrawn, it's as though it
has shifted to a different color palette.  Windows and dialog boxes, etc.,
have their expected shapes, likewise with swirls in the
background/wallpaper, but colors are now lime green, magenta, etc.,
instead of calming blue, and many fonts become blurry or ragged.  How is
that even possible?  Restarting the desktop does restore the expected
colors (but only if set for 1600x900).

Is there a simple "redraw screen" command (like Ctrl-L at the console)
that might work at the desktop, without requiring logout/login?

Re: Psychedelic GUI after stable update to buster

[hobie]

> On Fri, 12 Jul 2019 17:52:43 -0400
> ho...@rumormillnews.com wrote:
>
>>Following recent 'buster' move to 'stable' I got wild psychedelic colors
>>on my XFCE desktop, making it nearly impossible to read anything
>>on-screen.
>>
>>Normally I'd have display set for 1024x768.  I've found I can get normal
>>color on the GUI if I switch to 1600x900.  However, even then, if I
>> switch
>>to console (F1-F6) or if the screensaver comes on, on return the
>>psychedelic colors are back.  If I log out / log in to the desktop,
>> normal
>>colors return with the 1600x900 setting only.
>>
>>AMD A10-7860K Radeon R7.  ASUSTEK A68HM-K motherboard.
>>firmware-linux-free and firmware-linux-nonfree are installed.
>>
>>Is this a bug?  Is there a fix? I'd like to get my normal colors and
>>normal resolution back.  Thanks in advance for any help.
>>
>
>
> Try a different theme. The switch from GTK-2 to GTK-3 results in a mess
> if the wrong theme is used.
>

Thanks. :)  Using GTK-ChTheme (which says it's for GTK+ 2, but I don't see
a similar utility for GTK+ 3) I switched to Xfce 4.4 but got no
improvement.  Should I be approaching this theme change some other way?

Psychedelic GUI after stable update to buster

[hobie]

Following recent 'buster' move to 'stable' I got wild psychedelic colors
on my XFCE desktop, making it nearly impossible to read anything
on-screen.

Normally I'd have display set for 1024x768.  I've found I can get normal
color on the GUI if I switch to 1600x900.  However, even then, if I switch
to console (F1-F6) or if the screensaver comes on, on return the
psychedelic colors are back.  If I log out / log in to the desktop, normal
colors return with the 1600x900 setting only.

AMD A10-7860K Radeon R7.  ASUSTEK A68HM-K motherboard.
firmware-linux-free and firmware-linux-nonfree are installed.

Is this a bug?  Is there a fix? I'd like to get my normal colors and
normal resolution back.  Thanks in advance for any help.

Re: ALSA - Multiple Sources...? / Thanks

[hobie]

Just a note of thanks to Joel, Andrei and Florent. :)  I'll carry my
situation to the Audio users list and see what happens.  Thanks for the
time and the courteous comments.

--hobie

> On Thu, Nov 27, 2014 at 04:56:12AM -0500, ho...@rumormillnews.com wrote:
>> > On Jo, 27 nov 14, 03:03:33, ho...@rumormillnews.com wrote:
>> >> > On Wed, Nov 26, 2014 at 05:55:24PM -0500, ho...@rumormillnews.com
>> >> wrote:
>> >> >
>> >> > Do you know if pulseaudio is installed?
>> >> >
>> >> > dpkg -l | grep pulseaudio
>> >>
>> >> Hi, Joel - Thanks. :)  Synaptic says "no" but running the dpkg -l
>> >> command
>> >> indicates pulseaudio 2.0.3 is present. (!)  It isn't, but there's a
>> fair
>> >> number of residual files around from some earlier install, including
>> >> things like the gstreamer1.0-pulseaudio plugin and PulseAudio client
>> >> libraries.  I don't _think_ there's anything there that would cause
>> ALSA
>> >> to block...?
>> >
>> > Would you mind just copy-pasting the output of above command?
>> >
>> > BTW, interpreting the output of 'dpkg -l' would be easier if one would
>> > not use grep to strip the header with explanations and use only dpkg's
>> > built-in pattern support, in this particular case:
>> >
>> > dpkg -l '*pulseaudio*'
>> >
>> > Thanks,
>> > Andrei
>> > --
>>
>> Thanks, Andrei - here 'tis:
>>
>> Desired=Unknown/Install/Remove/Purge/Hold
>> |
>> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
>> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
>> ||/ Name   Version  Architecture Description
>> +++-==---=
>> ii  gstreamer0.10- 0.10.31-3+nm amd64GStreamer plugin for
>> PulseAudio
>> ii  gstreamer1.0-p 1.4.4-2  amd64GStreamer plugin for
>> PulseAudio
>> un  libsdl1.2debia   (no description available)
>> rc  pulseaudio 2.0-3amd64PulseAudio sound server
>> un  pulseaudio-eso   (no description available)
>> un  pulseaudio-mod   (no description available)
>> un  pulseaudio-uti   (no description available)
>
>
> Okay, no pulseaudio.
>
> This reference says you get dmix by default
> for ALSA, version above 1.0.9rc2. So several
> years.
>
> http://alsa.opensrc.org/Dmix
>
> You also want to make sure there is no asoundrc.
>
> Probably you will get better help if you post
> to Linux Audio Users mailing list.
>
> It may help to know the output of
>
> lspci
>
> cat /proc/asound/cards
>
> lsmod | grep snd
>
>
> Hope this helps
>
>
> --
> Joel Roth
>
>
>
>
> --
> To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/20141127103501.GA359@sprite
>
>


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/65689244064ef478e9046cefc3819056.squir...@dragon.rumormillnews.com

Re: ALSA - Multiple Sources...?

[hobie]

> On Jo, 27 nov 14, 03:03:33, ho...@rumormillnews.com wrote:
>> > On Wed, Nov 26, 2014 at 05:55:24PM -0500, ho...@rumormillnews.com
>> wrote:
>> >
>> > Do you know if pulseaudio is installed?
>> >
>> > dpkg -l | grep pulseaudio
>>
>> Hi, Joel - Thanks. :)  Synaptic says "no" but running the dpkg -l
>> command
>> indicates pulseaudio 2.0.3 is present. (!)  It isn't, but there's a fair
>> number of residual files around from some earlier install, including
>> things like the gstreamer1.0-pulseaudio plugin and PulseAudio client
>> libraries.  I don't _think_ there's anything there that would cause ALSA
>> to block...?
>
> Would you mind just copy-pasting the output of above command?
>
> BTW, interpreting the output of 'dpkg -l' would be easier if one would
> not use grep to strip the header with explanations and use only dpkg's
> built-in pattern support, in this particular case:
>
> dpkg -l '*pulseaudio*'
>
> Thanks,
> Andrei
> --

Thanks, Andrei - here 'tis:

Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  gstreamer0.10- 0.10.31-3+nm amd64GStreamer plugin for PulseAudio
ii  gstreamer1.0-p 1.4.4-2  amd64GStreamer plugin for PulseAudio
un  libsdl1.2debia   (no description available)
rc  pulseaudio 2.0-3amd64PulseAudio sound server
un  pulseaudio-eso   (no description available)
un  pulseaudio-mod   (no description available)
un  pulseaudio-uti   (no description available)

--hobie


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/e2bf01927e665ed49ef5f16f8d7a89ed.squir...@dragon.rumormillnews.com

Re: ALSA - Multiple Sources...?

[hobie]

> On Thu, Nov 27, 2014 at 03:03:33AM -0500, ho...@rumormillnews.com wrote:
>> > On Wed, Nov 26, 2014 at 05:55:24PM -0500, ho...@rumormillnews.com
>> wrote:
>> >> For years, ALSA has allowed me to have two apps open at one time -
>> for
>> >> example, a YouTube video could be playing in my browser while vlc was
>> >> also
>> >> open, paused on playback of a 3-hour mp3.
>> >>
>> >> That's changed with a recent Debian update.  Now, if a YouTube video
>> is
>> >> playing and I try to start vlc, I get an error message:
>> >>
>> >> The audio device "dmix:CARD=CK804,DEV=0" could not be used:
>> >> Device or resource busy.
>> >>
>> >> What changed with that recent update?  I have no idea.  After lots of
>> >> Internet searching, I put this into an .asoundrc file:
>> >>
>> >> -
>> >>
>> >> pcm.!default {
>> >> type plug
>> >> slave.pcm "dmixer"
>> >> }
>> >>
>> >> pcm.dmixer {
>> >> type dmix
>> >> ipc_key 1024
>> >> slave {
>> >> pcm "hw:0,0"
>> >> period_time 0
>> >> period_size 1024
>> >> buffer_size 4096
>> >> rate 44100
>> >> }
>> >> bindings {
>> >> 0 0
>> >> 1 1
>> >> }
>> >> }
>> >>
>> >> ctl.dmixer {
>> >> type hw
>> >> card 0
>> >>
>> >> -
>> >>
>> >> That made no meaningful change to the situation that I can see.  How
>> can
>> >> I
>> >> bring back the original ALSA behavior that served me so well for
>> years?
>> >
>> > Do you know if pulseaudio is installed?
>> >
>> > dpkg -l | grep pulseaudio
>> >
>> >
>> >> Thanks in advance.
>> >>
>> >> --hobie
>> >
>> > --
>> > Joel Roth
>>
>> Hi, Joel - Thanks. :)  Synaptic says "no" but running the dpkg -l
>> command
>> indicates pulseaudio 2.0.3 is present. (!)  It isn't, but there's a fair
>> number of residual files around from some earlier install, including
>> things like the gstreamer1.0-pulseaudio plugin and PulseAudio client
>> libraries.  I don't _think_ there's anything there that would cause ALSA
>> to block...?
>
> AIUI, that if pulseaudio is running, your programs are
> not getting direct access to ALSA. There is an additional
> layer.
>
> My expertise doesn't extend to pulse audio. I recall it adds
> some convenience, like being able to provide a separate
> volume control for each app, which can help in a GUI
> environment. Nothing I need.
>
> ALSA should default to mixing. You shouldn't need any
> special asoundrc to get that.
>
> I would be surprised if aptitude and dpkg reported
> different status for the same package!
>
> cheers,
>
> Joel
>

Agreed. :)  dpkg -l says:

 dpkg -l |grep pulseaudio
ii  gstreamer0.10-pulseaudio:amd64 
0.10.31-3+nmu4+b1  amd64GStreamer plugin for
PulseAudio
ii  gstreamer1.0-pulseaudio:amd64   1.4.4-2   
amd64GStreamer plugin for PulseAudio
rc  pulseaudio  2.0-3 
amd64PulseAudio sound server

Maybe the 'rc' at the start of that line has a meaning I don't know? 
Anyway - it looks like pulseaudio is not actually present.  I agree, too,
that ALSA should allow mixing without extra configuration.  That's what it
had been doing for years, until a recent update apparently changed
something.

--hobie


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/206f13c3de9ce1fe7e3f802ba4b5a1b0.squir...@dragon.rumormillnews.com

Re: ALSA - Multiple Sources...?

[hobie]

> On Wed, Nov 26, 2014 at 05:55:24PM -0500, ho...@rumormillnews.com wrote:
>> For years, ALSA has allowed me to have two apps open at one time - for
>> example, a YouTube video could be playing in my browser while vlc was
>> also
>> open, paused on playback of a 3-hour mp3.
>>
>> That's changed with a recent Debian update.  Now, if a YouTube video is
>> playing and I try to start vlc, I get an error message:
>>
>> The audio device "dmix:CARD=CK804,DEV=0" could not be used:
>> Device or resource busy.
>>
>> What changed with that recent update?  I have no idea.  After lots of
>> Internet searching, I put this into an .asoundrc file:
>>
>> -
>>
>> pcm.!default {
>> type plug
>> slave.pcm "dmixer"
>> }
>>
>> pcm.dmixer {
>> type dmix
>> ipc_key 1024
>> slave {
>> pcm "hw:0,0"
>> period_time 0
>> period_size 1024
>> buffer_size 4096
>> rate 44100
>> }
>> bindings {
>> 0 0
>> 1 1
>> }
>> }
>>
>> ctl.dmixer {
>> type hw
>> card 0
>>
>> -
>>
>> That made no meaningful change to the situation that I can see.  How can
>> I
>> bring back the original ALSA behavior that served me so well for years?
>
> Do you know if pulseaudio is installed?
>
> dpkg -l | grep pulseaudio
>
>
>> Thanks in advance.
>>
>> --hobie
>
> --
> Joel Roth

Hi, Joel - Thanks. :)  Synaptic says "no" but running the dpkg -l command
indicates pulseaudio 2.0.3 is present. (!)  It isn't, but there's a fair
number of residual files around from some earlier install, including
things like the gstreamer1.0-pulseaudio plugin and PulseAudio client
libraries.  I don't _think_ there's anything there that would cause ALSA
to block...?

--hobie


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/8742c1c487c002195804001716ae43e0.squir...@dragon.rumormillnews.com

ALSA - Multiple Sources...?

[hobie]

For years, ALSA has allowed me to have two apps open at one time - for
example, a YouTube video could be playing in my browser while vlc was also
open, paused on playback of a 3-hour mp3.

That's changed with a recent Debian update.  Now, if a YouTube video is
playing and I try to start vlc, I get an error message:

The audio device "dmix:CARD=CK804,DEV=0" could not be used:
Device or resource busy.

What changed with that recent update?  I have no idea.  After lots of
Internet searching, I put this into an .asoundrc file:

-

pcm.!default {
type plug
slave.pcm "dmixer"
}

pcm.dmixer {
type dmix
ipc_key 1024
slave {
pcm "hw:0,0"
period_time 0
period_size 1024
buffer_size 4096
rate 44100
}
bindings {
0 0
1 1
}
}

ctl.dmixer {
type hw
card 0

-

That made no meaningful change to the situation that I can see.  How can I
bring back the original ALSA behavior that served me so well for years?

Thanks in advance.

--hobie


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/c9c4e3b80378e1027ca1aae356b666b5.squir...@dragon.rumormillnews.com