Re: volume keys not working on thinkpad x201
On Sun, Mar 23, 2014 at 10:50:21AM +0100, Remi Locherer wrote: On Sat, Mar 22, 2014 at 04:31:22PM -0600, Theo de Raadt wrote: Date: Sat, 22 Mar 2014 21:49:19 +0100 (CET) From: remi.loche...@relo.ch With the snapshot from March 22 the volume keys on my ThinkPad x201 do not work anymore. mixerctl still works. Before I was running the snapshot from Feb 3 with which the volume keys worked. The volume keys still work. What changed is that the volume keys no longer control the hardware mixer directly anymore when you're running X. Instead the volume key events are passed to whatever X application is running. If you're running mplayer, you'll see that the volume keys still control the volume and give you feedback on the screen. If you run gnome, you'll see something similar. The problem you might experience is that the x201 boots up with the hardware mixer set to a fairly low level. And the software volume control in most X applications won't change it so you won't be able to go any higher by just pressing the volume keys. When several X applications are running which one should get the event? I cranked outputs.master to 200 and tested with smplayer and aqualung both playing something. The volume keys had no audible nor visual effect. Do volume keys work when smplayer and aqualung have the keyboard focus ? So we should take all our hardware mixers, and crank them to full volume right at boot time. Except that would be bad. So this indicates that the new mixer layer has a problem. The old behaviour where the volume keys manipulated outputs.master was more intuitive to me. yes but it doesn't work in all cases :(
radeondrm: losing console, X initially garbled
When this machine boots up it switches successfully to radeondrm but when X starts the display gets garbled [1]. Switching to the console and back again fixes the issue [2] but now the console is blank with the cursor blinking top left corner. It still accepts input though, and the X display is still fine. [1] http://tp76.info/radeondrm/bad.jpg [2] http://tp76.info/radeondrm/good.jpg OpenBSD 5.5-current (GENERIC.MP) #9: Wed Mar 19 18:15:43 MDT 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: AMD E2-2000 APU with Radeon(tm) HD Graphics (AuthenticAMD 686-class, 512KB L2 cache) 1.75 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,NXE,MMXX,FFXSR,LONG,SSE3,MWAIT,SSSE3,CX16,POPCNT,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,WDT,ITSC real mem = 2521862144 (2405MB) avail mem = 2468233216 (2353MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 12/22/11, SMBIOS rev. 2.7 @ 0xeb430 (39 entries) bios0: vendor American Megatrends Inc. version P03RBN.098.130409.KK date 04/09/2013 bios0: SAMSUNG ELECTRONICS CO., LTD. 275E4E/275E5E acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG MSDM HPET BGRT SSDT SSDT acpi0: wakeup devices SBAZ(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) P0PC(S4) PCE6(S4) PWRB(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD E2-2000 APU with Radeon(tm) HD Graphics (AuthenticAMD 686-class, 512KB L2 cache) 1.75 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,NXE,MMXX,FFXSR,LONG,SSE3,MWAIT,SSSE3,CX16,POPCNT,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,WDT,ITSC ioapic0 at mainbus0: apid 3 pa 0xfec0, version 21, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 3 (PE20) acpiprt2 at acpi0: bus -1 (PE21) acpiprt3 at acpi0: bus 6 (PE22) acpiprt4 at acpi0: bus -1 (PE23) acpiprt5 at acpi0: bus -1 (BR15) acpiprt6 at acpi0: bus -1 (PCE7) acpiprt7 at acpi0: bus -1 (PCE8) acpiprt8 at acpi0: bus 1 (PCE4) acpiprt9 at acpi0: bus -1 (PCE6) acpiec0 at acpi0 acpicpu0 at acpi0: C2, PSS acpicpu1 at acpi0: C2, PSS acpibtn0 at acpi0: PWRB acpiac0 at acpi0: AC unit offline acpibat0 at acpi0: BAT1 not present acpibtn1 at acpi0: LID_ acpivideo0 at acpi0: VGA_ acpivideo1 at acpi0: VGA_ acpivideo2 at acpi0: VGA_ bios0: ROM list: 0xc/0xee00 cpu0: 1747 MHz: speeds: 1750 1400 875 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 AMD AMD64 14h Host rev 0x00 radeondrm0 at pci0 dev 1 function 0 ATI Radeon HD 7340 rev 0x00 drm0 at radeondrm0 radeondrm0: msi azalia0 at pci0 dev 1 function 1 ATI Radeon HD 6310 HD Audio rev 0x00: msi azalia0: no supported codecs ppb0 at pci0 dev 4 function 0 AMD AMD64 14h PCIE rev 0x00: apic 3 int 16 pci1 at ppb0 bus 1 ahci0 at pci0 dev 17 function 0 AMD Hudson-2 SATA rev 0x40: msi, AHCI 1.3 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: ATA, HGST HTS545050A7, GG2O SCSI3 0/direct fixed naa.5000cca73ae5305b sd0: 476940MB, 512 bytes/sector, 976773168 sectors cd0 at scsibus0 targ 1 lun 0: Slimtype, DVD A DU8A5SH, NS21 ATAPI 5/cdrom removable ohci0 at pci0 dev 18 function 0 AMD Hudson-2 USB rev 0x11: apic 3 int 18, version 1.0, legacy support ehci0 at pci0 dev 18 function 2 AMD Hudson-2 USB2 rev 0x11: apic 3 int 17 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 AMD EHCI root hub rev 2.00/1.00 addr 1 ohci1 at pci0 dev 19 function 0 AMD Hudson-2 USB rev 0x11: apic 3 int 18, version 1.0, legacy support ehci1 at pci0 dev 19 function 2 AMD Hudson-2 USB2 rev 0x11: apic 3 int 17 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 AMD EHCI root hub rev 2.00/1.00 addr 1 piixpm0 at pci0 dev 20 function 0 AMD Hudson-2 SMBus rev 0x14: polling iic0 at piixpm0 spdmem0 at iic0 addr 0x51: 4GB DDR3 SDRAM PC3-12800 SO-DIMM azalia1 at pci0 dev 20 function 2 AMD Hudson-2 HD Audio rev 0x01: apic 3 int 16 azalia1: codecs: Realtek ALC269 audio0 at azalia1 pcib0 at pci0 dev 20 function 3 AMD Hudson-2 LPC rev 0x11 ppb1 at pci0 dev 20 function 4 AMD Hudson-2 PCI rev 0x40 pci2 at ppb1 bus 2 ohci2 at pci0 dev 20 function 5 AMD Hudson-2 USB rev 0x11: apic 3 int 18, version 1.0, legacy support sdhc0 at pci0 dev 20 function 7 AMD Hudson-2 SD Host Controller rev 0x00: apic 3 int 16 sdhc0 at 0x10: can't map registers ppb2 at pci0 dev 21 function 0 AMD Hudson-2 PCIE rev 0x00: apic 3 int 16 pci3 at ppb2 bus 3 Atheros AR9485 rev 0x01 at pci3 dev 0 function 0 not configured ppb3 at pci0 dev 21 function 2 AMD Hudson-2 PCIE rev 0x00 pci4 at ppb3 bus 6 re0 at
Re: volume keys not working on thinkpad x201
So we should take all our hardware mixers, and crank them to full volume right at boot time. IMO, this is the best option. When I do that, the audio circuits pick up noise from the hard drive. So there is backgorund noise all the time, even when I am not doing audio. If hardware mixer is too loud, we can attenuate the sound in software. The opposite in not possible, we can't increase the volume in software if the hardware is too quiet. Except that would be bad. So this indicates that the new mixer layer has a problem. Hardware defaults are too quiet, they have always been too quiet. I think there is a major disconnect here. The software level should control the hardware level. Or, this entire software layer should be removed. While the new mechanims is fancy, the old one worked right.
Re: radeondrm: losing console, X initially garbled
Date: Sun, 23 Mar 2014 14:37:49 +0100 From: Thomas Pfaff tpf...@tp76.info When this machine boots up it switches successfully to radeondrm but when X starts the display gets garbled [1]. Switching to the console and back again fixes the issue [2] but now the console is blank with the cursor blinking top left corner. It still accepts input though, and the X display is still fine. Without at least your Xorg.0.log there is not much we can do for you.
Re: volume keys not working on thinkpad x201
On Sun, Mar 23, 2014 at 14:22, Alexandre Ratchov wrote: So we should take all our hardware mixers, and crank them to full volume right at boot time. IMO, this is the best option. Strongest possible disagree. The keyboard beep on my thinkpads at full volume is mind shattering. Among other noises. I do not want to be in the situation where I'm hoping that sndiod will then soft lower the volume to an acceptable level. The fact that there is a mixer that mplayer is not aware of could be considered a feature. Across a variety of machines, running a variety of operating systems and software, I am constantly adjusting the volume up or down depending on the sitatuation because there is no one level that's perfect. I make the following observation about my emotional state when doing so: When I have to raise the volume, I am annoyed. When I have to lower the volume, I am *angry*. Hardware defaults are too quiet, they have always been too quiet. I think that's fine. Quiet is secure by default. :) We ship a default /etc/mixerctl.conf with a commented entry that raises the volume. If people want loud, it's an easy change to make.
Re: volume keys not working on thinkpad x201
On Sun, Mar 23, 2014 at 14:22, Alexandre Ratchov wrote: So we should take all our hardware mixers, and crank them to full volume right at boot time. IMO, this is the best option. Strongest possible disagree. The keyboard beep on my thinkpads at full volume is mind shattering. Among other noises. I do not want to be in the situation where I'm hoping that sndiod will then soft lower the volume to an acceptable level. The fact that there is a mixer that mplayer is not aware of could be considered a feature. Across a variety of machines, running a variety of operating systems and software, I am constantly adjusting the volume up or down depending on the sitatuation because there is no one level that's perfect. I make the following observation about my emotional state when doing so: When I have to raise the volume, I am annoyed. When I have to lower the volume, I am *angry*. Hardware defaults are too quiet, they have always been too quiet. I think that's fine. Quiet is secure by default. :) We ship a default /etc/mixerctl.conf with a commented entry that raises the volume. If people want loud, it's an easy change to make. The two mixers model is broken. There should only be one mixer. The software mixer should notice when hardware mixer changes happen behind the scene. The software mixer should also tune the hardware mixer itself into a high or low range. Basically, somewhere along the way writing this code Alexandre started to think that users could cope with a multi-control mixer board. That is not realistic.
Re: volume keys not working on thinkpad x201
So we should take all our hardware mixers, and crank them to full volume right at boot time. IMO, this is the best option. Do you have a stereo system connected to your PC? I would not made this the default. Start low and if you want a loud default setting, use mixerctl.conf If hardware mixer is too loud, we can attenuate the sound in software. The opposite in not possible, we can't increase the volume in software if the hardware is too quiet. Except that would be bad. So this indicates that the new mixer layer has a problem. Hardware defaults are too quiet, they have always been too quiet. I think there is a major disconnect here. The software level should control the hardware level. Or, this entire software layer should be removed. While the new mechanims is fancy, the old one worked right. Sound volume controll is higly user specific, and it troubles me with every OS I use. Especially if there is more than one sound card attached (e.g. USB Headset on a Laptop). And then different sound inputs (mostly software, firefox, media player, system sounds) all coming in with different line levels (volumes)... I would also like the up/down/mute keys actuating the hardware outputs. - Ben
ehci: kernel diagnostic assertion (reg 0x3) == 0 failed
Synopsis: ehci: kernel diagnostic assertion (reg 0x3) == 0 failed Category: amd64 Environment: System : OpenBSD 5.5 Details : OpenBSD 5.5-current (GENERIC) #18: Sat Mar 22 22:41:35 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC Architecture: OpenBSD.amd64 Machine : amd64 Description: A kernel diagnostic assertion regarding ehci happens during early boot. This is an old Lenovo which I upgrade from time to time when I have access to it. How-To-Repeat: Boot a /bsd kernel. /bsd.rd works fine. Fix: Unknown. I work around this by disabling ehci with config(8). ddb (copied by hand): ehci0 at pci0 dev 3 function 3 SiS 7002 USB rev 0x00: apic 2 int 23 panic: kernel diagnostic assertion (reg 0x3) == 0 failed: file ../../../ arch/amd64/pci/pci_machdep.c, line 272 Stopped at Debugger+0x5: leave Debugger() at Debugger+0x5 panic() at panic+0xee __assert() at __assert+0x21 pci_conf_read() at pci_conf_read+0xdd ehci_pci_takecontroller() at ehci_pci_takecontroller+0x6b ehci_pci_attach() at ehci_pci_attach+0x22a config_attach() at config_attach+0x1bc pci_probe_device() at pci_probe_device+0x447 pci_enumerate_bus() at pci_enumerate_bus+0xe9 config_attach() at config_attach+0x1bc end trace frame: 0x81edce80, count: 0 RUN AT LEASE 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb trace Debugger() at Debugger+0x5 panic() at panic+0xee __assert() at __assert+0x21 pci_conf_read() at pci_conf_read+0xdd ehci_pci_takecontroller() at ehci_pci_takecontroller+0x6b ehci_pci_attach() at ehci_pci_attach+0x22a config_attach() at config_attach+0x1bc pci_probe_device() at pci_probe_device+0x447 pci_enumerate_bus() at pci_enumerate_bus+0xe9 config_attach() at config_attach+0x1bc mainbus_attach() at mainbus_attach+0x163 config_attach() at config_attach+0x1bc cpu_configure() at cpu_configure+0x17 main() at main+0x41c end trace frame: 0x0, count: -14 ddb ps PID PPID PGRPUID S FLAGS WAIT COMMAND *0 -1 0 0 7 0x200 swapper ddb dmesg (RAMDISK_CD): OpenBSD 5.5-current (RAMDISK_CD) #18: Sat Mar 22 22:53:39 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 1056899072 (1007MB) avail mem = 1023336448 (975MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf0100 (32 entries) bios0: vendor LENOVO version 40KT27A date 06/13/2007 bios0: LENOVO 8818D34 acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) CPU 3.20GHz, 3201.30 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,CNXT-ID,CX16,xTPR,NXE,LONG,LAHF,PERF cpu0: 256KB 64b/line 4-way L2 cache cpu0: apic clock running at 133MHz ioapic0 at mainbus0: apid 2 pa 0xfec0, version 14, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 SiS 661 PCI rev 0x11 ppb0 at pci0 dev 1 function 0 SiS 648FX AGP rev 0x00 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 NVIDIA GeForce4 MX 420 rev 0xa3 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) SiS 964 ISA rev 0x36 at pci0 dev 2 function 0 not configured pciide0 at pci0 dev 2 function 5 SiS 5513 EIDE rev 0x01: 661: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility atapiscsi0 at pciide0 channel 0 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: TSSTcorp, DVD-ROM TS-H352C, IB02 ATAPI 5/cdrom removable cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 disabled (no drives) SiS 7012 AC97 rev 0xa0 at pci0 dev 2 function 7 not configured ohci0 at pci0 dev 3 function 0 SiS 5597/5598 USB rev 0x0f: apic 2 int 20, version 1.0, legacy support ohci1 at pci0 dev 3 function 1 SiS 5597/5598 USB rev 0x0f: apic 2 int 21, version 1.0, legacy support ohci2 at pci0 dev 3 function 2 SiS 5597/5598 USB rev 0x0f: apic 2 int 22, version 1.0, legacy support ehci0 at pci0 dev 3 function 3 SiS 7002 USB rev 0x00: apic 2 int 23 ehci0: reset timeout ehci0: init failed, error=13 pciide1 at pci0 dev 5 function 0 SiS 180 SATA rev 0x01: DMA pciide1: using apic 2 int 17 for native-PCI interrupt wd0 at pciide1 channel 0 drive 0: HDS728080PLA380 40Y9028LEN wd0: 16-sector PIO, LBA48, 76324MB, 156312576 sectors wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 6 re0 at pci0 dev 15 function 0 Realtek 8169 rev 0x10: RTL8110S (0x0400), apic 2 int 17, address XXX rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 0 usb0 at ohci0: USB revision 1.0 uhub0 at usb0 SiS OHCI root hub rev 1.00/1.00 addr 1 usb1 at ohci1: USB revision 1.0 uhub1 at usb1 SiS OHCI root hub rev
Re: volume keys not working on thinkpad x201
So we should take all our hardware mixers, and crank them to full volume right at boot time. IMO, this is the best option. Do you have a stereo system connected to your PC? I would not made this the default. Start low and if you want a loud default setting, use mixerctl.conf So that is the reason why my car stereo has two sets of volume control knobs. with the second set located inside the engine compartment, so I have to stop at the side of the road, pop open the hood, and reach down along the hot engine to near where the oil filter is. It is ridiculous to have two layers of volume control. It is unfriendly.
Re: ehci: kernel diagnostic assertion (reg 0x3) == 0 failed
Date: Sun, 23 Mar 2014 17:53:47 +0100 (CET) From: Donovan Watteau tso...@gmail.com ehci0 at pci0 dev 3 function 3 SiS 7002 USB rev 0x00: apic 2 int 23 panic: kernel diagnostic assertion (reg 0x3) == 0 failed: file ../../../ arch/amd64/pci/pci_machdep.c, line 272 Stopped atDebugger+0x5: leave Debugger() at Debugger+0x5 panic() at panic+0xee __assert() at __assert+0x21 pci_conf_read() at pci_conf_read+0xdd ehci_pci_takecontroller() at ehci_pci_takecontroller+0x6b ehci_pci_attach() at ehci_pci_attach+0x22a config_attach() at config_attach+0x1bc pci_probe_device() at pci_probe_device+0x447 pci_enumerate_bus() at pci_enumerate_bus+0xe9 config_attach() at config_attach+0x1bc end trace frame: 0x81edce80, count: 0 RUN AT LEASE 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb trace Debugger() at Debugger+0x5 panic() at panic+0xee __assert() at __assert+0x21 pci_conf_read() at pci_conf_read+0xdd ehci_pci_takecontroller() at ehci_pci_takecontroller+0x6b ehci_pci_attach() at ehci_pci_attach+0x22a config_attach() at config_attach+0x1bc pci_probe_device() at pci_probe_device+0x447 pci_enumerate_bus() at pci_enumerate_bus+0xe9 config_attach() at config_attach+0x1bc mainbus_attach() at mainbus_attach+0x163 config_attach() at config_attach+0x1bc cpu_configure() at cpu_configure+0x17 main() at main+0x41c end trace frame: 0x0, count: -14 ddb ps PID PPID PGRPUID S FLAGS WAIT COMMAND *0 -1 0 0 7 0x200 swapper ddb Can you send the output of pcidump -vxx from that machine?
Re: volume keys not working on thinkpad x201
On Sun, Mar 23, 2014 at 11:52:49AM -0400, Ted Unangst wrote: On Sun, Mar 23, 2014 at 14:22, Alexandre Ratchov wrote: So we should take all our hardware mixers, and crank them to full volume right at boot time. IMO, this is the best option. Strongest possible disagree. so, diff to fix pckbd(4) is welcome.
Re: volume keys not working on thinkpad x201
On Sun, Mar 23, 2014 at 11:52:49AM -0400, Ted Unangst wrote: On Sun, Mar 23, 2014 at 14:22, Alexandre Ratchov wrote: So we should take all our hardware mixers, and crank them to full volume right at boot time. IMO, this is the best option. Strongest possible disagree. so, diff to fix pckbd(4) is welcome. The problem is not with the keyboard controllers. The issue is that libsndiod does not watch manipulate the hardware mixer. It ignores a critical piece of the machine, which worked fine before.
Re: volume keys not working on thinkpad x201
On Sun, Mar 23, 2014 at 11:56:44AM -0600, Theo de Raadt wrote: On Sun, Mar 23, 2014 at 11:52:49AM -0400, Ted Unangst wrote: On Sun, Mar 23, 2014 at 14:22, Alexandre Ratchov wrote: So we should take all our hardware mixers, and crank them to full volume right at boot time. IMO, this is the best option. Strongest possible disagree. so, diff to fix pckbd(4) is welcome. The problem is not with the keyboard controllers. The issue is that libsndiod does not watch manipulate the hardware mixer. libsndio never made use of the hardware mixer. The old mixer is still there. It hasn't changed. Just rebuild your kernel, and keep using it. It ignores a critical piece of the machine, which worked fine before. the mixer didn't change since 2008
Re: volume keys not working on thinkpad x201
On Sun, Mar 23, 2014 at 11:38:11AM -0600, Theo de Raadt wrote: So we should take all our hardware mixers, and crank them to full volume right at boot time. IMO, this is the best option. Do you have a stereo system connected to your PC? I would not made this the default. Start low and if you want a loud default setting, use mixerctl.conf So that is the reason why my car stereo has two sets of volume control knobs. with the second set located inside the engine compartment, so I have to stop at the side of the road, pop open the hood, and reach down along the hot engine to near where the oil filter is. It is ridiculous to have two layers of volume control. It is unfriendly. 100% agreed. We should have one mixer only.
Re: volume keys not working on thinkpad x201
On Sun, Mar 23, 2014 at 18:53, Alexandre Ratchov wrote: On Sun, Mar 23, 2014 at 11:52:49AM -0400, Ted Unangst wrote: On Sun, Mar 23, 2014 at 14:22, Alexandre Ratchov wrote: So we should take all our hardware mixers, and crank them to full volume right at boot time. IMO, this is the best option. Strongest possible disagree. so, diff to fix pckbd(4) is welcome. The current situation isn't perfect, but at least I can live with it, or have figured out how to cope. Slamming outputs.master=255 would be way worse than the current situation. There are sounds, like the beep made when suspending and resuming, that do not go through sndiod. Maxing out the hardware volume is not a viable option.
Re: radeondrm: losing console, X initially garbled
Date: Sun, 23 Mar 2014 16:57:37 +0100 From: Thomas Pfaff tpf...@tp76.info On Sun, 23 Mar 2014 16:46:52 +0100 (CET) Mark Kettenis mark.kette...@xs4all.nl wrote: Date: Sun, 23 Mar 2014 14:37:49 +0100 From: Thomas Pfaff tpf...@tp76.info When this machine boots up it switches successfully to radeondrm but when X starts the display gets garbled [1]. Switching to the console and back again fixes the issue [2] but now the console is blank with the cursor blinking top left corner. It still accepts input though, and the X display is still fine. Without at least your Xorg.0.log there is not much we can do for you. Oops, sorry about that! [16.186] (==) Using config file: /etc/xorg.conf So what's in your config file? My bet is that you're forcing Xorg to use the vesa(4) driver there. That doesn't quite work anymore now that we have KMS. If this was the only reason you created an xorg.conf, delete it. Otherwise remove that the lines that configure the vesa(4) driver. The radeon(4) driver should work with your hardware now.
Re: volume keys not working on thinkpad x201
Slamming outputs.master=255 would be way worse than the current situation. There are sounds, like the beep made when suspending and resuming, that do not go through sndiod. Maxing out the hardware volume is not a viable option. suspend/resume and text console beeps usually run through pcppi(4), which volume is not necessarily controlled by the audio device (especially on systems without onboard audio devices). There is no easy way to have the volume settings shown by mixerctl apply to this. And, to the best of my knowledge, the kernel has no way to know whether the pcppi wave generator goes through the audio device, or directly reaches the speaker.
Re: volume keys not working on thinkpad x201
On Sun, Mar 23, 2014 at 18:24, Miod Vallat wrote: Slamming outputs.master=255 would be way worse than the current situation. There are sounds, like the beep made when suspending and resuming, that do not go through sndiod. Maxing out the hardware volume is not a viable option. suspend/resume and text console beeps usually run through pcppi(4), which volume is not necessarily controlled by the audio device (especially on systems without onboard audio devices). There is no easy way to have the volume settings shown by mixerctl apply to this. And, to the best of my knowledge, the kernel has no way to know whether the pcppi wave generator goes through the audio device, or directly reaches the speaker. All true. Since we're talking about thinkpads, I will note that outputs.master does control the volume of the beeper because in this particular case it is wired up that way on most models I'm familiar with. I don't expect or ask that mixerctl work with the beeper, just pointing out that we cannot assume the opposite, that the audio mixer won't affect the beeper.
Re: radeondrm: losing console, X initially garbled
On Sun, 23 Mar 2014 19:23:50 +0100 (CET) Mark Kettenis mark.kette...@xs4all.nl wrote: When this machine boots up it switches successfully to radeondrm but when X starts the display gets garbled [1]. Switching to the console and back again fixes the issue [2] but now the console is blank with the cursor blinking top left corner. It still accepts input though, and the X display is still fine. Without at least your Xorg.0.log there is not much we can do for you. Oops, sorry about that! [16.186] (==) Using config file: /etc/xorg.conf So what's in your config file? My bet is that you're forcing Xorg to use the vesa(4) driver there. That doesn't quite work anymore now that we have KMS. If this was the only reason you created an xorg.conf, delete it. Otherwise remove that the lines that configure the vesa(4) driver. The radeon(4) driver should work with your hardware now. gah, yeah I created an xorg.conf ages ago, probably because of issues with radeondrm and I completely forgot about it. Removed xorg.conf and things are working just fine. Suspend/resume does not work, though, but that's another (actual) bug report I guess. Thanks, and appologies for the retarded bug report.
Re: volume keys not working on thinkpad x201
Date: Sun, 23 Mar 2014 14:51:24 -0400 From: Ted Unangst t...@tedunangst.com On Sun, Mar 23, 2014 at 18:24, Miod Vallat wrote: Slamming outputs.master=255 would be way worse than the current situation. There are sounds, like the beep made when suspending and resuming, that do not go through sndiod. Maxing out the hardware volume is not a viable option. suspend/resume and text console beeps usually run through pcppi(4), which volume is not necessarily controlled by the audio device (especially on systems without onboard audio devices). There is no easy way to have the volume settings shown by mixerctl apply to this. And, to the best of my knowledge, the kernel has no way to know whether the pcppi wave generator goes through the audio device, or directly reaches the speaker. All true. Since we're talking about thinkpads, I will note that outputs.master does control the volume of the beeper because in this particular case it is wired up that way on most models I'm familiar with. I don't expect or ask that mixerctl work with the beeper, just pointing out that we cannot assume the opposite, that the audio mixer won't affect the beeper. Note that on some machines where the beeper goes through the hardware mixer, there is an inputs.beep that controls its (relative) volume.
Re: volume keys not working on thinkpad x201
On Sun, Mar 23, 2014 at 02:27:57PM +0100, Alexandre Ratchov wrote: On Sun, Mar 23, 2014 at 10:50:21AM +0100, Remi Locherer wrote: On Sat, Mar 22, 2014 at 04:31:22PM -0600, Theo de Raadt wrote: Date: Sat, 22 Mar 2014 21:49:19 +0100 (CET) From: remi.loche...@relo.ch With the snapshot from March 22 the volume keys on my ThinkPad x201 do not work anymore. mixerctl still works. Before I was running the snapshot from Feb 3 with which the volume keys worked. The volume keys still work. What changed is that the volume keys no longer control the hardware mixer directly anymore when you're running X. Instead the volume key events are passed to whatever X application is running. If you're running mplayer, you'll see that the volume keys still control the volume and give you feedback on the screen. If you run gnome, you'll see something similar. The problem you might experience is that the x201 boots up with the hardware mixer set to a fairly low level. And the software volume control in most X applications won't change it so you won't be able to go any higher by just pressing the volume keys. When several X applications are running which one should get the event? I cranked outputs.master to 200 and tested with smplayer and aqualung both playing something. The volume keys had no audible nor visual effect. Do volume keys work when smplayer and aqualung have the keyboard focus ? No, it does not work with smplayer and aqualung. But it works with mplayer when it has the focus. So we should take all our hardware mixers, and crank them to full volume right at boot time. Except that would be bad. So this indicates that the new mixer layer has a problem. The old behaviour where the volume keys manipulated outputs.master was more intuitive to me. yes but it doesn't work in all cases :(
