| === stgraber_ is now known as stgraber | ||
| === AceLan_ is now known as AceLan | ||
| ppisati | yo | 07:05 |
|---|---|---|
| cristian_c | Hi | 08:37 |
| cristian_c | I've opened this bug report much time ago: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/972604 | 08:38 |
| ubot2` | Launchpad bug 972604 in linux (Ubuntu) "168c:001c [HP Compaq Presario C700 Notebook PC] Wireless led button doesn't switch colors" [Low,Triaged] | 08:38 |
| cristian_c | I was told to open an upstream bug report | 08:38 |
| cristian_c | I've read it, but I've got some doubt: | 08:39 |
| cristian_c | for example: Please take care that when you provide the below information, you should be booted into the newest available upstream mainline kernel only. Failure to do this will have negative unintended consequences. | 08:39 |
| cristian_c | What kernel does it refer, exactly? | 08:40 |
| cristian_c | And then: While booted into the newest mainline kernel only describe how the bug is reproducible in the latest mainline kernel only. If this is a regression, please note the specific commit. | 08:40 |
| cristian_c | How can I find the commit? | 08:40 |
| cristian_c | Any ideas? | 08:40 |
| smb | cristian_c, Mainline kernel packages you can find at http://kernel.ubuntu.com/~kernel-ppa/mainline/ and about the regression part; if you never saw that working, then I would just assume this is not a regression. | 08:54 |
| cristian_c | smb, it's not a regression | 08:58 |
| smb | So, you just should clearly say that when doing an upstream bug report. And for confirmation try the latest mainline kernel (3.14-rc6) to see it has not been by chance fixed. | 09:00 |
| cristian_c | smb, I was told that a new bug report would be open for the regression, instead | 09:00 |
| smb | Which regression ? | 09:00 |
| cristian_c | smb, th regression that I found trying 3.13.0-031300rc5 | 09:01 |
| cristian_c | smb, the orginal bug never has been resolved in many years | 09:01 |
| cristian_c | *original | 09:02 |
| cristian_c | smb, then, should I assume 3.14-rc6 kernel in the upstream bug report? | 09:03 |
| smb | Ah ok. So you would check with 3.14-rc whether that regression still happens (as well as in theory the leds thing). But if wireless works otherwise and its just the led I would not have too high hopes for ever getting them to work. | 09:03 |
| cristian_c | smb, but the workaround worked | 09:04 |
| cristian_c | before | 09:04 |
| cristian_c | smb, but reversed | 09:04 |
| cristian_c | and the there is the regression too | 09:04 |
| cristian_c | *then | 09:04 |
| cristian_c | smb, I've tried the 3.14 and the regression is confirmed | 09:05 |
| smb | cristian_c, So whatever the regression is (I have not read through the whole old report), you should open a new report for that and first try to resolve this in that report. For that you should try to figure out roughly when this happened (you could use the mainline kernels for that, too) | 09:08 |
| cristian_c | smb, ok | 09:09 |
| smb | cristian_c, Joe should be around on this channel a bit later. I see he had been working on the bug | 09:09 |
| cristian_c | smb, he has told me to open an upstream bug report | 09:10 |
| cristian_c | *that I should open | 09:10 |
| cristian_c | smb, I can open a new bug report for the regression | 09:10 |
| cristian_c | smb, but always in launchpad? | 09:10 |
| cristian_c | or upstream? | 09:10 |
| smb | cristian_c, Ultimately upstream as you verified its still a problem in 3.14. Though one also can open a launchpad bug, too and link that to the upstream bug (can be done later, too). Depends a bit on how Joe would like to handle it | 09:14 |
| smb | cristian_c, So just something in general. I must admit I have some difficulties understanding all the leds and buttons, expected behaviour and what the regression is. Might be just me as a non-native speaker but it general keep it as simple as possible and assume the reader has no clue how your laptop looks like. ;) | 09:27 |
| cristian_c | smb, the laptop has got a button with led | 09:28 |
| smb | By the way you can add a bit more info (and/or debug a bit more) by adding info what is in /sys/class/leds (that should have all the available leds). Also cat of trigger inside a led dir gives the available triggers. | 09:29 |
| smb | cristian_c, In the bug, irc is a bad media for info | 09:29 |
| cristian_c | it has got two states: enable/disabled , shown respectively with blue/red lights | 09:29 |
| cristian_c | smb, ok | 09:29 |
| cristian_c | smb, but I've already explained it in the report | 09:30 |
| smb | Also when you have written "none" to the trigger, you could manually play around with brightness. max_brigtness has the upper value | 09:30 |
| cristian_c | :) | 09:30 |
| cristian_c | smb, I'll try to add info about /sys/class in the report | 09:31 |
| cristian_c | *more info | 09:31 |
| smb | cristian_c, Sure and I understand you expect that led to be red when off (could be only if the radio is off or no transmition) | 09:31 |
| smb | and green when transmitting something | 09:32 |
| cristian_c | smb, workaround works, but lights are reversed, then there isn't a brightness problem | 09:33 |
| cristian_c | with workaround | 09:33 |
| smb | The workaround looks like you let the radio trigger the rx led (receive) instead of the tx (transmit) | 09:33 |
| cristian_c | <smb> cristian_c, Sure and I understand you expect that led to be red when off (could be only if the radio is off or no transmition) | 09:33 |
| cristian_c | smb, exactly, the led should look red when wifi is off, and blue when wifi is on, but situation is inverted -> red light with wifi on and blue with wifi off | 09:35 |
| cristian_c | after performing the workaround, obviously | 09:35 |
| cristian_c | smb, before performing workaround, led i blinking | 09:36 |
| cristian_c | as it was related to network activity and not to wifi status | 09:36 |
| cristian_c | *led is | 09:37 |
| smb | cristian_c, So I am just guessing from the names of the led files phy0::tx and rx, the intention for those is signalling sending and receiving. I cannot tell whether there is more of them | 09:38 |
| smb | Like I said you could examine a bit what they do (colorwise) (its just one physically?) when you disable all triggers and write values into brightness | 09:39 |
| cristian_c | smb, there is only a led button | 09:44 |
| cristian_c | *wifi | 09:44 |
| cristian_c | then, there are the classic leds for laptops | 09:44 |
| cristian_c | *little leds (without buttons): power, hard disk, wifi, ... | 09:45 |
| cristian_c | smb, I've already tried to change values | 09:46 |
| cristian_c | and play with triggers, but I've never found a trick | 09:46 |
| cristian_c | It needs only the color reverse | 09:47 |
| smb | Ok, so the ath5k driver (or whatever) exports multiple logical leds for the same one (as it seems). Assuming a kind of multicolour led. Activating one end makes it glow red, the other blue. I am not really sure what the phy0radio trigger relates to, and whether there maybe is another phy0... one. A lot of these things only show up with the right modules loaded which gets triggered by the specific hardware found. | 09:50 |
| apw | ppisati, hey about ? this led thing, is there any reason to build that in for anything other than arm* ? | 10:22 |
| ppisati | apw: nope AFAIK but i built-in in every arch just for coherence among them | 10:23 |
| ppisati | apw: if you prefer an armhf only, i'll do | 10:23 |
| apw | ppisati, i think that makes a little more sense yeah, and note i have pushed a start new release | 10:24 |
| apw | ppisati, i am happy to apply it manually as well | 10:24 |
| ppisati | apw: ok, i'll refresh the patchset | 10:24 |
| apw | ack | 10:24 |
| cristian_c | smb, I'll control these and I'll add more info in the launchpad bug report | 10:59 |
| smb | cristian_c, Thanks | 11:17 |
| smb | cking, apw btw, bug 1291930 | 11:18 |
| ubot2` | Launchpad bug 1291930 in unity (Ubuntu) "Menus do not work while VNC screen of virt-manager is active" [Undecided,New] https://launchpad.net/bugs/1291930 | 11:18 |
| cking | smb, i've confirmed it too | 11:19 |
| cking | rtg, https://wiki.ubuntu.com/Kernel/PowerManagement/ThermalIssues | 12:29 |
| === cmagina is now known as cmagina-away | ||
| infinity | .win 58 | 15:16 |
| === cmagina-away is now known as cmagina | ||
| apw | missed | 15:51 |
| === awe__ is now known as awe | ||
| mjg59 | sforshee: I have a pile of patches for switcheroo and gmux that work for me here | 17:52 |
| mjg59 | sforshee: http://www.codon.org.uk/~mjg59/retina_patches/ | 17:52 |
| sforshee | mjg59: that url isn't working for me | 18:03 |
| mjg59 | sforshee: Sorry, http://www.codon.org.uk/~mjg59/tmp/retina_patches/ | 18:10 |
| === TheDrums is now known as DalekSec | ||
| slangasek | apw, ogasawara: is there a wiki page I can refer to that explains the support cycle for the HWE stacks? | 18:17 |
| ogasawara | slangasek: yep, just a sec | 18:17 |
| ogasawara | slangasek: https://wiki.ubuntu.com/Kernel/Support | 18:18 |
| ogasawara | slangasek: that's got a few different views | 18:18 |
| ogasawara | slangasek: depending on the level of granularity you want | 18:18 |
| ogasawara | slangasek: https://wiki.ubuntu.com/Kernel/LTSEnablementStack | 18:18 |
| ogasawara | slangasek: and that is the horribly verbose version | 18:18 |
| slangasek | ogasawara: thanks | 18:19 |
| sforshee | mjg59: ah, you're using switcheroo to pass the edid to i915. Good idea. | 18:20 |
| sforshee | mjg59: so I no longer have the machine with gmux and lvds that I could test this with. I gave it to mlankhorst, not sure if he still has it. | 18:21 |
| sforshee | but he isn't in this channel. I'll check with him. | 18:21 |
| infinity | BenC: New SRU round for you. | 21:03 |
| infinity | BenC: https://bugs.launchpad.net/ubuntu/+source/linux-ppc/+bug/1291125 | 21:03 |
| ubot2 | Launchpad bug 1291125 in Kernel SRU Workflow "linux-ppc: <version to be filled> -proposed tracker" [Medium,In progress] | 21:03 |
| BenC | infinity: ACK | 21:06 |
| infinity | zequence: New lowlatency rebases for you for Q and S, nothing for P this time. | 23:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!