=== _salem is now known as salem_ [03:16] ok so just as lxc ships one lxc-net script which is called by all init scripts, i'd like to do the same for qemu [03:16] but where should that script go? [03:16] lxc places it into /usr/lib/x86-64-gnu/lxc/ === Malsasa is now known as Guest73312 === Malsasa_ is now known as Malsasa === salem_ is now known as _salem [07:03] good morning [07:03] hi dholbach :) [07:04] hi LocutusOfBorg1 [07:35] diwic: hi! It's about the front jack detection in my GA motherboard, we exchanged a couple of mails some week ago; please tell me when you have a minute [07:41] mardy, pong [07:41] diwic: so, after all it seems that the jack detection is fuzzy even in my machine [07:42] mardy, okay [07:42] diwic: more often than not, when I insert the headphones in the front panel, the headphones do not appear in the system settings -> sound panel [07:43] diwic: I need to run some more tests, but I've the feeling that if I boot my PC with the headphones in, then they are detected (but if I then remove them and reinsert them, they might go undetected again) [07:45] mardy, IIRC in some state some people have seen the jack detection go on and off repeatedly, but I'm not sure if that is when the headphone is plugged in or unplugged [07:45] diwic: also, I feel that the headset detection starts working rather reliably sometimes, probably if I play with the card/alsa in a certain way [07:46] diwic: well, my problem is that sometimes the headphones are in but they are not detected; it never happened to me that it detected non-existing headphones [07:48] diwic: do you have a bug #, for the issue your patch fixed? [07:49] mardy, pad.lv/1248116 [08:12] diwic: so, my problem is that while I insert the headphones, I see them quickly appearing and disappearing a few times in the System Settings -> Sound panel [08:13] diwic: sometimes the final state is that they are correctly detected, sometimes they aren't [08:13] diwic: it seems to be rather random [08:14] mardy, so your jack detection is not reliable, and therefore the original patch makes sense to keep for you as well? [08:14] diwic: but the flakyness is only while I insert the headspeakers: once the card/driver has decided if it wants to see them or not, the state won't change [08:15] diwic: no, I prefer to run with model=nofixup, and if the headphones are not detected, I pull them out and try again [08:16] diwic: because I get the annoying audio clicks only while inserting the jack; before and after that, the sound is always stable [08:16] mardy, ok. Maybe this behaviour is varying between individual motherboard units of the exact same model and revision === Malsasa is now known as Guest62445 === Malsasa_ is now known as Malsasa === Malsasa_ is now known as Malsasa === Malsasa_ is now known as Malsasa === jamesh__ is now known as jamesh === masACC is now known as maswan [12:01] FYI, I've just uploaded dash to wily with a privilege dropping patch. If anyone gets some sort of regression with it, let me know. === Malsasa is now known as Guest99038 === Malsasa_ is now known as Malsasa === tvoss is now known as tvoss|afk [12:33] stgraber: ok for qemu's kvm init script i intend to put the body of it under /usr/share/qemu/init (calling it from the sysv, systemd, and upstart jobs). is thatan ok place? [12:34] (lxc places them under /usr/lib/x86-64-linux-gnu/ but that seems a little unorthodox) [12:34] (and hard to get right in the qemu build system) === rickspencer3_ is now known as rickspencer3 === maxb_ is now known as maxb === Malsasa is now known as Guest1836 === Malsasa_ is now known as Malsasa [14:31] do we assume that /usr/share is mounted by runlevel2? i assume so... [14:42] hallyn: yep, that seems fine. [14:42] cool, thanks. bunch of testing of course required (as i'm also merging the two scripts) [14:43] hm, i wonder if i should move the init script to qemu-system-common, since it should error out cleanly on other arches anyway [15:01] hardware-kernel interaction question for someone if you've got a few moments. A question on Ask Ubuntu was created saying they want to enable "USB Charge While Off" on their laptop that supposedly supports it. As I understand the feature, that's controlled at the hardware / BIOS level, not the kernel. Am I wrong on that? Sorry if the wrong location for this... [15:01] o [15:01] i'm not a kernel expert, nor a hardware expert, hence the question [15:03] teward: yeah, that is a hardware thing. [15:04] dobey: mind if I link you to the bug and the question and the discussion then for your two cents? [15:04] since i'm obviously not an expert [15:04] dobey: because apparently Sony says its enabled via "Windows Power Management" so thereby the equivalent would be the kernel in Ubuntu [15:05] i mean, i'm not a kernel developer/expert either, but it doesn't take a PhD to see that the kernel can't control hardware while the kernel isn't running [15:05] but as I understand that kind of hardware feature that's a hardware-control-level feature, NOT something that can just be toggled by the kernel. [15:05] dobey: indeed. [15:05] dobey: would anyone on the kernel team have any ideas on this? [15:05] (and should I go poke them) [15:05] well, maybe sony implemented it in such a way that they require you to configure it within windows itself [15:06] which would mean that you could theoretically chagne the same setting in ubuntu, if sony provided the driver to do so [15:06] teward: you can ask in #ubuntu-kernel i guess [15:06] i might, thanks [15:07] (doesn't take a kernel expert, though, to determine the hardware has to control things when the system is off xd) [15:07] my guess is sony won't support ubuntu, and you'll need to dual boot to be able to change that setting in windows [15:07] dobey: that's my guess as well [15:50] seb128: Your ubuntu-settings upload to vivid seems to remove a previous fix. https://launchpadlibrarian.net/208087396/ubuntu-settings_15.04.2_15.04.3.diff.gz [15:53] bdmurray, ok, thanks for spotting it, can you reject it? I'm going to fix it [15:55] seb128: done [16:00] bdmurray, thanks === tvoss|afk is now known as tvoss === tvoss is now known as tvoss|eod === tvoss|eod is now known as tvoss [21:03] * hallyn peeks in looking for doko [22:58] who knows why this test failure happened? https://jenkins.qa.ubuntu.com/job/wily-adt-kio/ARCH=amd64,label=adt/15/console