[gentoo-user] Graphics Card Advice
Hi, I have just bought a RX 5600 XT and after a few issues with screen freezing after kernel starts loading, resolved by compiling EFIFB (no previous FB compiled in) the card has been working fine for 2 days booting normally. The machine then started not to boot, not even to get to BIOS (so you couldn't even press DEL to get to BIOS screen). I took the card out and replaced with old card and PC started fine. I tried this 4 times and still with new card PC would not even POST. I don't have a little speaker to here if there are any beeps. I am returning the card as it feels like that is the problem but have a nagging suspicion this could be some other problem like power supply. I have 700W coolermaster PSU which should be ample (according to websites) but is 9 years (amazingly they had the foresight to provide 8 and 6 pin cables which were both plugged in). My next issue is do I get another 5600 XT (different brand) or are nvidia equivalent better? I have always been an AMD fan. Could I end up in the same boat. PC spec - ASUS 470 Pro MB with 2700 Ryzen. Any advice would be much appreciated? John
[gentoo-user] transparent compression? (e.g. device mapper for compression)
hi - any nice way to have compression at the file system level, without using zfs? perhaps some kind of device mapper that compresses data? i find file system compression to speed up read/write to slow disks noticeably (e.g. sata). rgrds, cm.
Re: [gentoo-user] USB sound
On Wednesday, 29 April 2020 16:24:31 BST Peter Humphrey wrote: > On Wednesday, 29 April 2020 10:15:09 BST Peter Humphrey wrote: > > I'm still puzzled at why creating an asound.conf enabled - phonon? - to > > pick the right device. Alsa is not installed here, apart from alsa-lib; > > no applications. > > Well, that was a hostage to fortune. Today, after a reboot and power cycle > for maintenance work, I'm back to having no sound. > > I suspected the devices of having been detected in the wrong order, but > /proc/ asound/cards seemed to be pointing to the right one. Besides, it > seemed unlikely that a USB device would be found and set up before the > device in the display controller. The PCI card 0 is initialised before USB hotplugging takes place. Therefore the asound.conf content would be parsed by alsa and the appropriate audio card # (USB) would/should be set as the default device. However, the device initialisation sequencing logic can be upset. It is possible things will get messy if you have a second USB audio device, in your case a webcam. I don't know if USB devices are always hotplugged in a predictable order, but I guess plugging/unplugging USB devices could change the order in which they are being detected and consequently their numbering. Therefore your card number in asound.conf could end up referencing the other USB device. > Next was to blacklist all the intel* modules and reboot again. Just the one > card found now, the USB device. Still no sound. The fact there is no intel-snd module shows your sound problem is not related to the PCI device. I expect the snd-usb-audio module was loaded though? There are three kernel/alsa centric solutions I can think of, but may be more. The first and simpler is to name your USB device in asound.conf not by card number, but by the name it is recognised as. Run: cat /proc/asound/cards then look at the name enclosed in [square brackets] after the card number and use that. There may be other naming conventions but unless I search for it I'm not sure what to advise. Obviouisly if you have two USB devices identified as "USB" this solution won't work. Another way is manage the order in which the USB devices are ordered when the module initialises them. Create a /etc/module.d/alsa.conf file and add this: alias snd-card-0 snd-usb-audio alias snd-card-1 snd-usb-audio options snd-usb-audio index=0,1 vid=0x,0x pid=0x,0x Where vendor and product IDs can be obtained and entered in the desired order by looking at the corresponding device output of lsusb. A third way is to create some udev rule(s) in /etc/udev/rules.d/ - see here for syntax: https://alsa.opensrc.org/Udev and here for different examples: https://github.com/dh1tw/remoteAudio/wiki/Persistent-USB-Mapping-of-Audio-devices-(Linux) > Have I to go the PulseAudio route after all? You do not *have to*, but if you find the PulseAudio server and associated GUI/CLI tools are convenient for you, then you can set up USE=pulseaudio and use that to mix your sound sinks and sources devices with. As Canek has already posted in most cases it just works. However, I must confess I had a spate of pa processes racing up to 100% CPU and annoyingly respawning each time I tried to kill it. An update eventually fixed this problem and it worked fine ever since. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] USB sound
On Wed, Apr 29, 2020 at 10:24 AM Peter Humphrey
wrote:
[...]
> Have I to go the PulseAudio route after all?
>
Hi Peter; I had refrained to comment in this thread since I had nothing to
contribute regarding your original question. However, since you now ask if
you should go to the PA route, I'm going to put my two cents on the issue.
I moved to PulseAudio with Gnome 2.26 more than a decade ago, in 2009. I've
some small issues with it through the years, but the worst case scenario
always has been resolved with a quick "pulseaudio -k", and even that has
happened four or five times in all these years. Also, I do not work with
audio professionally, but I do use several audio sources and sinks
(including Bluetooth headphones and USB microphones) and since the
quarantine I had to record video for online courses, using the USB
microphone integrated to my webcam. PulseAudio usually just works™,
specially if you use its own tools, like pavucontrol.
(It also works incredible well with flatpak and Valve Proton in Steam,
which allows me the play Windows games in Linux almost flawlessly.)
For me, the most annoying thing I had to do with PulseAudio has been that
sometimes I need to plug and unplug a headphone jack connector so the sound
automatically goes through it. That's it.
However this easy of use (specially with plug-and-play) comes with a cost:
you are surrendering control of the audio stack to PulseAudio *completely*.
You can configure it inside the confines that PulseAudio itself defines;
but if you enable PulseAudio and you try to fight it, you ARE going to
lose. This is a feature; not a bug.
I use my Gentoo machines to work (and sometimes to play a video game); not
to learn the intricacies of ALSA. I'm fine with PulseAudio making the shots
regarding anything sound related; it's the same reason I use Gnome and
systemd. But I know a lot of people (specially Gentoo users) have *very*
strong feelings about the control they believe they have over the software
they use and that they usually didn't wrote nor contributed to it. As a
professional programmer and a college programming professor, I like to
think I know better.
If you want to keep 100% control on the audio in your system (or to believe
you have said control), in my experience what will happen is exactly your
current scenario: the moment your hardware is a little more dynamic than an
integrated or PCIe sound card, everything goes off the rails. Then is time
for the litany of searching the web and asking for help until it kinda
works, sometimes, except on Wednesdays and when it's raining... and then
you change a little your system and you need to start all over again.
Or you can try to trust a piece of software specifically written to handle
this kind of scenarios. But then you have to truly trust it; and with the
knowledge that it *WILL* sometimes fail, because no software is perfect.
I choose the second.
Now some concrete advise, if you choose to go the PulseAudio route:
1. Remove your user from the audio group.
2. Delete any /etc/asound* files
3. Delete any ${HOME}/.asoundrc file
4. Don't modify any file on /etc/pulse
It should just work™. Otherwise there is a piece of software or user/system
configuration trying to fight PulseAudio. That will not turn out OK.
Regards.
--
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México
Re: [gentoo-user] prevent users from shutting down while other users logged in
On Wed, 29 Apr 2020 16:19:29 +, Raffaele BELARDI wrote: > I often have the kids working on my main ~amd64 PC (XFCE, OpenRC, > -consolekit) while I ssh into it doing some maintenance from an old PC. > Often they shut it down without telling me first, so I loose part of my > stuff. Is there a way to tell XFCE/elogind/PAM/lightdm/whoever to not > allow shutdown from a regular user while another user is logged in? I > understand that logind/systemd provides the system-inhibit [1] user > command just for that, but I don't find the analogous for > OpenRC/elogind. > > Basically I'd like that: > - if there is more than one user logged in, either locally via lighdm > or remotely via SSH, the shutdown XFCE button is grayed out. Once all > users except one have logged out, the button is again available Can you configure the shutdown/reboot command called by XFCE? If so, you can set it to a script that checks whether anyone else is logged in before either executing the shutdown or displaying a "Daddy's using the computer" dialog. -- Neil Bothwick A seminar on time travel will be held 2 weeks ago. pgpJu6bMYXGf7.pgp Description: OpenPGP digital signature
Re: [gentoo-user] USB sound
On Wed, Apr 29, 2020 at 8:25 AM Peter Humphrey wrote: > > On Wednesday, 29 April 2020 10:15:09 BST Peter Humphrey wrote: > > > I'm still puzzled at why creating an asound.conf enabled - phonon? - to pick > > the right device. Alsa is not installed here, apart from alsa-lib; no > > applications. > > Well, that was a hostage to fortune. Today, after a reboot and power cycle for > maintenance work, I'm back to having no sound. > > I suspected the devices of having been detected in the wrong order, but /proc/ > asound/cards seemed to be pointing to the right one. Besides, it seemed > unlikely that a USB device would be found and set up before the device in the > display controller. > > Next was to blacklist all the intel* modules and reboot again. Just the one > card found now, the USB device. Still no sound. > > Have I to go the PulseAudio route after all? > > -- > Regards, > Peter. Sorry for your problems. I thought we were done with this also. No, I don't think you should add pulseaudio. It might be a good solution in the end, if you want to have both the USB and HDMI sound paths or you just want more visibility when you are using multiple sound application. (If you ever do) However if you just want USB then blacklist snd_hda_intel and you should have only 1 sound card, the USB device which is my understanding of where you are now. This seems to vary from USB to USB device but does alsamixer give you any control over the device? Possibly the volume is just off? You can determine which card (if any in your case) is being fed audio by watching different versions of the info file: cat /proc/asound/card1/pcm0p/info That path name can vary a bit with multiple cards in the system but it you only have one it's hopefully pretty close. When audio is not playing the last line should tell you you have a subdevice available. When audio plays the subdevice being used becomes unavailable. In your case I'd be interested in whether the audio is getting to the USB device or going someplace else? Again, sorry for your problems. Mark
Re: [gentoo-user] prevent users from shutting down while other users logged in
On Wed, Apr 29, 2020 at 11:19 AM Raffaele BELARDI wrote: > I often have the kids working on my main ~amd64 PC (XFCE, OpenRC, > -consolekit) while I ssh into it doing some maintenance from an old PC. > Often they shut it down without telling me first, so I loose part of my > stuff. Is there a way to tell XFCE/elogind/PAM/lightdm/whoever to not allow > shutdown from a regular user while another user is logged in? I understand > that logind/systemd provides the system-inhibit [1] user command just for > that, but I don’t find the analogous for OpenRC/elogind. > > > > Basically I’d like that: > > - if there is more than one user logged in, either locally via lighdm or > remotely via SSH, the shutdown XFCE button is grayed out. Once all users > except one have logged out, the button is again available > > - from the ssh shell the command would be always available (root or normal > user, I don’t care) > > - permanently disabling the shutdown for the kids is not optimal, they > should be able to stop the machine if he/she is the only user > > > > Thanks, > > > > raffaele > > > > [1] https://www.freedesktop.org/software/systemd/man/systemd-inhibit.html > > > What's to stop them from shutdown via the physical power button? I know that's almost always how I shut down a computer, and I tend not to even think of using the menu. As for how to inhibit, you'll probably need to combine something that reads the currently active user sessions, with a patch to the XFCE menu to use that information.
[gentoo-user] prevent users from shutting down while other users logged in
I often have the kids working on my main ~amd64 PC (XFCE, OpenRC, -consolekit) while I ssh into it doing some maintenance from an old PC. Often they shut it down without telling me first, so I loose part of my stuff. Is there a way to tell XFCE/elogind/PAM/lightdm/whoever to not allow shutdown from a regular user while another user is logged in? I understand that logind/systemd provides the system-inhibit [1] user command just for that, but I don't find the analogous for OpenRC/elogind. Basically I'd like that: - if there is more than one user logged in, either locally via lighdm or remotely via SSH, the shutdown XFCE button is grayed out. Once all users except one have logged out, the button is again available - from the ssh shell the command would be always available (root or normal user, I don't care) - permanently disabling the shutdown for the kids is not optimal, they should be able to stop the machine if he/she is the only user Thanks, raffaele [1] https://www.freedesktop.org/software/systemd/man/systemd-inhibit.html
Re: [gentoo-user] USB sound
On Wednesday, 29 April 2020 10:15:09 BST Peter Humphrey wrote: > I'm still puzzled at why creating an asound.conf enabled - phonon? - to pick > the right device. Alsa is not installed here, apart from alsa-lib; no > applications. Well, that was a hostage to fortune. Today, after a reboot and power cycle for maintenance work, I'm back to having no sound. I suspected the devices of having been detected in the wrong order, but /proc/ asound/cards seemed to be pointing to the right one. Besides, it seemed unlikely that a USB device would be found and set up before the device in the display controller. Next was to blacklist all the intel* modules and reboot again. Just the one card found now, the USB device. Still no sound. Have I to go the PulseAudio route after all? -- Regards, Peter.
Re: [gentoo-user] USB sound
On Tuesday, 28 April 2020 23:41:59 BST Michael wrote: > On Tuesday, 28 April 2020 19:29:18 BST Mark Knecht wrote: > > On Tue, Apr 28, 2020 at 8:11 AM Peter Humphrey > > wrote: > > > On Tuesday, 28 April 2020 15:21:09 BST Mark Knecht wrote: > > Ah, so now we have more clues about what's going on. KDE supplies > > pulseaudio. AFAIK it's part of the KDE installation on other distros. I'm > > running Kubuntu LTS, not Gentoo, so I have pulseaudio because it's what > > the Kubuntu guys give me. You have a USE flag that __YOU__ took > > responsibility for turning off. (I'm not clear from this discussion what > > packages have a pulseaudio flag - multiple packages I assume? > > I don't think pa is part of KDE, unless you install it along with systemd. > Otherwise, KDE's phonon can be installed with the pulseaudio USE flag > enabled, in which case pa is dragged in. > > media-libs/phonon > Available versions: > 4.11.1-r1 [debug designer gstreamer pulseaudio +vlc] > Installed versions: 4.11.1-r1(10:37:13 04/12/19)(vlc -debug -designer > - gstreamer -pulseaudio) > Homepage:https://phonon.kde.org/ > Description: KDE multimedia abstraction library That's exactly the same as mine. > > Or your choice to disable USE flags has removed some of the 'features' of > > KDE. Again, I'm using completely updated stable Kubuntu LTS for my > > day-to-day systems so there are clearly differences. However I suggest > > here that the reason there is no multimedia under audio in system settings > > may be because you haven't included the pulseaudio USE flag. > > I think with openrc the pulseaudio USE flag is optional, but haven't looked > into the profile to see what it enables. [Sepulchrally] Confirmed. (Remember ORAC?) > > If Alsa under the hood is doing everything you need then let's drop the > > pulseaudio part. pulseaudio is conceptually just a mixer. > > Yes, and if some application requires pulseaudio, I think the apulse package > provides a partial implementation of the PulseAudio API and libraries for > alsa to use instead its own dmix, dsnoop, and plug plugins in place of > pulseaudio. > > Have you blacklisted the snd_hda_intel driver, at least as a test? If so, > > do you only see the USB card and the snd_usb_driver in /proc/asound? If so > > do you have sound from the USB device? > > With a broken sound card which will never work again, blacklisting the > snd_hda_intel driver is a 'sound' strategy (sorry, couldn't resist the pun). I may do that yet, but pro tem I'll leave it as it's doing no harm. The faulty device is switched off in the BIOS, so having Intel modules loaded implies that the Radeon's display driver needs it. > > I have nothing against creating an asound.conf file, if you want to, but I > > don't have any recent experience with doing that. However it should allow > > you to set your USB device as default if it's done correctly but in this > > test configuration with blacklisted snd_hda_intel drivers I don't think > > it's necessary and cannot see how it improves anything yet. > > > > Mark > > Right, an asound.conf file is just a way of configuring alsa itself to > select an audio card as a primary device, rather than disabling a device at > a kernel driver level. Both approaches will work equally, although > blacklisting a driver means it will be disabled for any other audio devices > which may need it in the future. I'm still puzzled at why creating an asound.conf enabled - phonon? - to pick the right device. Alsa is not installed here, apart from alsa-lib; no applications. -- Regards, Peter.
