Ralphred

Why? What is the criteria for the difference, redundancy, HA or homework? If it's the latter, feel free to go fourth and multiple - alone.

It does what I tell it to, nothing more, nothing less.

XRANDR is the xorg extension that changed (some of) the nomenclature of config files and allows userland alteration beyond pre-defined modelines, it's the backbone of "modern automagical" configurations, which is fine when it works, but as I said a PITA to deal with when it doesn't. output DP-2 mode 3840x1600@143.998Hz can be fixed in xorg.conf (as it should be), but (like I said, again) only people who read man xorg.conf and old school admins know how to do it.

Yep, these "1.2v NiCad" cells were ubiquitous when non-lead acid rechargeable batteries hit the market, and were considered "rechargeable replacements" for standard 1.5v alkaline/acid single use cells. The low internal resistance lead to the revolution of higher current uses, such as your screwdriver. Because of the charge/voltage curves it was common to charge them as "a single unit" (whether in parallel or series) with low current trickle chargers. Searching for "1.2v rechargeable tagged cell" from suppliers like Farnell.com, rswww.com or newark.com should yield a list of results that are suitable NiMH replacements, BUT I'd check with the local "mom & pop" electronic model store first; these cells were extensively used for model cars/boats etc. If you have the original charger it should be fine with NiMH cells, if not you want a current limited and voltage limited trickle charger: Charging time should be around 9~10 hours, so current limit appropriately for the capacity of the cells, and if in series limit to 3v. Personally I'd tap the "middle tags" and create a 2 circuit charger with high initial current burst that tails off into trickle charging after ~1.3v per circuit, as the NiMH cells can handle that. DON'T use a charger for lithium based cells, the charge/voltage curve is different and the best case scenario is shortened battery life/sub-optimally charged cells.

Just post the output of fstab; you need to edit the two drives it's checking for so they actually match yours.

It can be, but they will be mounted purely in "userspace", usually in /run/user[id] somewhere. It may or may not be consistent (regarding naming and mount location), and is probably being run after you login as it needs your valid credentials to do so. TBQH putting the relevant entries in /etc/fstab would probably solve the issue, as local filesystems are mounted early on in the boot process, this will also allow you to create consistant mount points.

Obviously @YoungBlade's script does what is says, wait 10 seconds, then starts steam. I do have "some processes" that require "other things" to be in place before continuing, and tend to use a until or while loop. This is a quick hackey edit of one for my "wait for" scripts to suit your needs: #!/bin/bash wait_for(){ limit=1 until grep -q "$1" /proc/mounts;do if [[ $limit -gt 40 ]] ;then echo "Timeout waiting for $1!" exit 1 else limit=$(( limit + 1 )) fi sleep 0.25 done echo "$1 mounted OK" } wait_for "/dev/sdb1" wait_for "/dev/sdc1" steam The idea here being; the script will check if the listed drive is mounted, every 1/4 of a second until it is mounted, then move on to the next drive to check. How we reach the `10 second timeout value` is "if [[ $limit -gt 40 ]] ;then", 40 x 1/4 of a second = 10 seconds.

It needs a config file. xf86confg crafting used to be the bread and butter of UI linux users, a skill lost to time because of XRANDR...

Yeah, that's the sound server "using" the device you are trying to modify. I've never used pipewire, so I can't tell you how to stop it. I would tell you to just uninstall it until we know ALSA works properly, but your package manager will no doubt try and uninstall deps too, at which point your DE disappears. If anyone knows how to stop pipewire autostarting/running a global daemon etc that'd be useful right now. As said above, you can't push the modifications whilst it's in use. That's a good idea, you can drop to a tty console, shut down the UI and nerf pulseaudio at the same time. When you are "testing audio" you need to do it with aplay -D hw:1,0 sample.wav, but because it's a different kernel/distro checking what you are trying to play sound through is still `card 1 device 0` with aplay -l first is a must. Need to diagnose that, split the command in two and tell me which one caused that specific error, then `ls` the directory it's pointing at.

That's the line that actually pushes the updated config. I can't help but think it's pipewire preventing the config going through. Try killall -SIGKILL pipewire; echo 1 > /sys/class/sound/hwC1D0/reconfig Read this too https://www.kernel.org/doc/html/v4.17/sound/hd-audio/notes.html#hd-audio-reconfiguration and the Early Patching section, so we are "singing from the same hymn sheet".

Is one of them in brackets? like cat /sys/power/mem_sleep [s2idle] deep if not set to s2idle with `echo s2idle>/sys/power/mem_sleep` and cat it again to see the "setting". The kernel docs have the relationship between the names and states: Technically "suspend" would make a copy of memory on disk the same as hibernate (specified on the kernel command line /proc/cmdline with resume=[something] or in the .config as PM_STD_PARTITION) itself but only go into the hibernate state after being in a form of [suspend to ram|s2idle|standby] for a set period (my laptop is an hour - one hour in standby then goes full hibernate). So, if you are missing the config for hibernate, then "suspend" may fail because of that, hence trying to do things at a very low level by just echoing "freeze" into /sys/power/state and try to recover from that. If that works then move onto the hibernation set-up by setting a resume= on the kernel command line (depends on your bootloader as to where to do that) and making sure hibernation works alone with echo "disk">/sys/power/state. If the drive is still playing up after that my next step would be to set the NVME driver to static instead of a module (if it isn't already, I've never done linux with disk drivers as loadable modules). EDIT: from the kernel docs page Found it interesting is all...

Debian. You can install all the kali tools yourself, and try out all the different desktop environments at the same time with debian. Once you know what you like you can go shopping for a distro that matches your wants without so much post install fondling, until then Debian.

Aye, a new glibc can totally btfo some older games that "used to just werk". Running them through steam and proton is great, you can keep "old versions" of proton around with little space cost compared to a game, the "correct version" of libraries etc are kept around in the "steam linux runtime", and games will always work. I know it's not a "philosophically ideal" situation, but more games working must = better user experience so...

I've always used grub, so no feedback on your bootloader. Yeah, "man xorg.conf" is one of the best man pages ever written TBH, but the automation added with the XRANDR extension can be a PITA to work around if it doesn't automagically work. The KDE kscreen2 daemon that is supposed to do post login set-up of monitors is pretty good, but has caused me issues in the past post screensaver activation or resuming from sleep states, so I tend to sidestep it and do things manually with X. I've not used nv driver for a very long time on a multi GPU system, but it should behave. Running "Xorg -configure" as root should be a good starting point for an xorg.conf, post that and we can start "tinkering".

Hibernation needs a specific set-up to work properly. How are you initiating sleep, with "echo mem>/sys/power/state"? What does cat /sys/power/mem_sleep return? Is /sys/power/sync_on_suspend set?

So this is the script that does the same thing as running hdajackretask and ticking the right boxes etc... #!/bin/sh #use aplay|grep to match the correct device and awk|sed get a card number card=$(aplay -l |grep "sofhdadsp \[sof-hda-dsp\], device 0: HDA Analog"|awk '{print $2}'|sed 's/://') #insert the number into the correct format for /sys/class/sound/* CARD="hwC${card}D0" #push the pin configs echo "0x12 0x411111f0" > /sys/class/sound/${CARD}/user_pin_configs echo "0x13 0x40000000" > /sys/class/sound/${CARD}/user_pin_configs echo "0x14 0x90170151" > /sys/class/sound/${CARD}/user_pin_configs echo "0x17 0x90170110" > /sys/class/sound/${CARD}/user_pin_configs echo "0x18 0x411111f0" > /sys/class/sound/${CARD}/user_pin_configs echo "0x19 0x03a11040" > /sys/class/sound/${CARD}/user_pin_configs echo "0x1a 0x411111f0" > /sys/class/sound/${CARD}/user_pin_configs echo "0x1b 0x411111f0" > /sys/class/sound/${CARD}/user_pin_configs echo "0x1d 0x40600001" > /sys/class/sound/${CARD}/user_pin_configs echo "0x1e 0x90170150" > /sys/class/sound/${CARD}/user_pin_configs echo "0x21 0x03211020" > /sys/class/sound/${CARD}/user_pin_configs #tell kernel to read updated config echo 1 > /sys/class/sound/${CARD}/reconfig You could hardcode the "/sys/class/sound/hwC1D0/user_pin_configs", but if you were to boot with some USB headphone or similar attached, it might shit the bed, so discovery within the script is more robust. Save this as /bin/soundcard_start.sh Run chmod u+x /bin/soundcard_start.sh so it's executable Run soundcard_start.sh as root and check it works. What init system are you using? Then we can write an automation script so it runs at boot.

So, if you run it as root, when you click "Apply boot override" it should stick the mappings in /lib/firmware/hda-jack-retask.fw, and make the kernel read them with an entry in /etc/modprobe.d/hda-jack-retask.conf. If both these files are there and it doesn't apply at boot time, post the contents of /lib/firmware/hda-jack-retask.fw and I can write a wrapper script round it.

Just a quick note as to why this is "unsupported": It isn't really unsupported, just there is no official configuration for the driver available in the kernel (the mapping). This is firmly HP's fault, they brought this hardware configuration into existence, and didn't submit a patch to the mainline kernel for it. I don't patch my re-maps into my kernel because they are preferences and not "fixes", but if you get this working I should be able to write the patch for yours.

amixer is the just cli version of alsamixer it's just a volume control app, but it's written for a command line interface. Open up alsamixer instead, press f6 and select the correct card (which seems to be only 1), then press f5 to see all the controls. Make sure nothing that isn't to do with a microphone (at this stage) isn't muted (press 'm' when a channel is selected). Also turn all the channels up to full, apart from master which I'd suggest is about 60%. Play your sound again, see if it makes noise. There is (may be) more to do, but the posts about getting ALC245 to work are ~2 years old, so instead of jumping in at the hdajackretask level (poking at the driver to make it do what you want) best practice is to work backwards and make sure there isn't something simpler causing the issue. hda-jack-retask is a userspace tool for mapping soundcard outputs to real world hardware outputs: Your soundcard driver will report a bunch of outputs to the kernel, then uses a "map" to tell it which of those outputs is front speakers, headphones, mic input etc. Using the hdajackretask program to manually re-map the outputs is fine, but there are caveats: If anything is using the sound card it'll fail to re-map, and you'll want to capture the "re-mapping" so you can automate it later on (this automation needs to be done before and sound server starts of it fail to re-map as with the program). I stole this screenshot from an "I fixed it" post: Note the "show unconnected pins" being checked. If your hdajackretask doesn't look exactly the same, post an image here. "Install Boot override" may or may not work depending on your distro/set-up, but don't worry we can always "force" it to work in other ways.

Firstly, the modern sound systems (jack, pulseaudio, pipewire) all sit on top of alsa, so if you are checking that "drivers are working" it's a alsa utils that you want to use to verify this. aplay is a small sound playback utility for alsa, that has the ability to play .wav files directly without any higher level sound server (like pipewire). Before you start grab yourself a .wav file for later, and stick it in ~. aplay -l (lowercase L) will give a summarised list of available hardware for playback. aplay -l **** List of PLAYBACK Hardware Devices **** card 0: HDMI [HDA ATI HDMI], device 3: Generic Digital [Generic Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: HDMI_1 [HDA ATI HDMI], device 3: Generic Digital [Generic Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: Generic [HD-Audio Generic], device 0: ALC1220 Analog [ALC1220 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: Generic [HD-Audio Generic], device 1: ALC1220 Digital [ALC1220 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 From this example you can see that 'card 0' is a gfx card, with device 3 being a plugged in monitor I could "send" sound to, 'card 1' is another gfx card with another monitor plugged in on the device 3 slot. 'card 2' is my actual sound card, with 2 playback devices, device 0 being analogue (re: speaker/headphones jack sockets) and device 1 being the digital S/PDIF socket. We aren't interested in sending sound to monitors with no speakers so we'll ignore cards 0 & 1, and just work with 2. I also don't have anything connected to the S/PDIF, so we aren't interested in card 2 device 1: This leaves the output we want to test as card 2 device 0, represented by hw:2,0. To test the sound we use aplay -D hw:2,0 sample.wav There are 3 results you can get if do this right: aplay says it's playing the sound, you hear sound aplay says it's playing the sound, you hear silence aplay says: audio open error: Device or resource busy In case of 1, happy days, it works. In case of 2, almost happy days, the sound is muted, use amixer to fix that In case of 3, pipewire has exclusive control of that device (but your list-sinks output suggests that isn't the case), kill it will 'killall [propcessname]' and try again. Once you get sound this way, everything else is just settings you have to alter to make your sound server behave the way you want it to by default, but your driver question is answered.

Yep, the .iso file has it's own filesystem defined within it, you just have to copy it to a drive (note drive, not partition or extant filesystem).

Just as a general note, when you are in a terminal (bash session) there is a really helpful function called "tab completion". You can read a little about it here. But basically, if you start typing a command or path, by pressing the tab key bash will try to auto-complete the word you have started, so if you were to type: cd ~/Down[tab][enter] sudo dpkg -i shad[tab] is should turn those lines into cd ~/Downloads sudo dpkg -i shadow-amd64.deb It's really useful for checking thing exist/you are in the right directory/spelling odd names etc. EDIT: If you had downloaded a picture, maybe "shadow_and_light.jpg", when you hit [tab] in the ~/Downloads directory, it would sound the "bell" because there are two files that would match the "shad" part: If you hit [tab] again it will list the "possible matches" for you, so you could type 'shadow-' and hit [tab] a third time for the correct completion.

Discord is a web app, you have to "trick" it into doing what you want by creating another "input device" that it will use as a mic. It's a chore to do, but can be done with alsa, pulse, pipewire or jack, jack would just be simpler in this use case to add another "pulse source" that will show up in discords list, then route what you want to it (OBS).

You can do it with jack: Mix your mic (assuming you use one) into a single stream with OBS' output and send that to discord instead of whatever it's using now.

Whilst there (probably) won't be legacy fixes for this, it's been "fixed" since Elden Ring was made available on Steamdeck.