| OvenWerks | Eickmeyer: re headphones... | 01:45 |
|---|---|---|
| OvenWerks | I have two computers to work from, One is a lap top but does not have separate level controls for speakers and headphones, It seems the jack physically switches and so it works fine even with jack in control of the device | 01:47 |
| OvenWerks | This computer does have separate level controls (Phones and front) but... the case is old enough that the jacks are AC97 compliant and do not have plug detection :) | 01:48 |
| OvenWerks | So plugging in a set of phones is not detected :P | 01:49 |
| OvenWerks | That is problem one... hard to test here. | 01:49 |
| OvenWerks | problem two: there is not a dbus signal it seems. Rather this is done by acpi | 01:51 |
| OvenWerks | I was thinking that this would mean system as there is a directory in /etc where scripts can be put to act on acpi events | 01:56 |
| OvenWerks | however, I am now thinking tha if I can run acpi_listen without sudo then I should be able to see events from userland | 01:57 |
| * OvenWerks is looking at https://github.com/ltworf/python-acpi/blob/master/acpi.py | 02:20 | |
| OvenWerks | this is user space. The relevent code is lines 119-121 to initialize and then the while (1) loop lines 146 and 147 (the stuff below that is not import to us as ours will be different. | 02:24 |
| OvenWerks | Problems with this, there is no sleep() in the while loop. That would use a lot of cpu unless... the socket read is blocking | 02:27 |
| Eickmeyer | OvenWerks: Maybe it's a state in /proc? | 02:31 |
| OvenWerks | That would mean threading to do that :( and once I do that, I have a loop running anyway and it may as well look through files every once in a while. | 02:31 |
| OvenWerks | lets see. | 02:31 |
| OvenWerks | The only mention of phone is the alsa level and mute | 02:37 |
| OvenWerks | I am looking in /proc/asound/PCH/ | 02:39 |
| Eickmeyer | teward, tsimonq2, sarnold: Could any of you tell me what I'm doing wrong? I can't get lintian-overrides to take: https://code.launchpad.net/~eeickmeyer/+git/raysession | 02:40 |
| sarnold | Eickmeyer: I think I'd try removing the | 02:44 |
| sarnold | sigh stupid new keyboard I'm still getting used to it | 02:45 |
| Eickmeyer | hehe | 02:45 |
| sarnold | " #python3 " kinds of things | 02:45 |
| Eickmeyer | Huh. Having that worked before in Carla, but I'll give it a go. | 02:46 |
| sarnold | oh. bummer. that was my only guess :) | 02:49 |
| Eickmeyer | Well, as I look at the docs, it says it's not necessary, but I think it was recognized as a comment on the same line. Either way, Giving it a shot. | 02:50 |
| Eickmeyer | sarnold: Nope, didn't work. | 02:53 |
| sarnold | :( | 02:54 |
| sarnold | thanks for reporting back | 02:54 |
| sarnold | it' | 02:54 |
| sarnold | s probasbly best that didn't do the job, though. heh | 02:54 |
| Eickmeyer | sarnold: All good, and yes, you're right. If it had worked, that means that comment parsing was bad in lintian. | 02:54 |
| sarnold | yeah :) | 02:55 |
| OvenWerks | Eickmeyer: looking more closely at /proc/asound/PCH/codec, it apears the information _is_ there but it is different for each machine. On my machine it seems to be two entries for "HP", one for mic and one for "out" | 15:23 |
| Eickmeyer | OvenWerks: Then how on earth does ALSA detect and automute? There's an option in alsamixer that tells it whether or not to auto mute the speakers if headphones are detected. Maybe it's something even lower-level? | 15:24 |
| OvenWerks | using acpi even to send a dbus message seems the best idea. | 15:24 |
| Eickmeyer | Must be. | 15:24 |
| OvenWerks | Eickmeyer: I am sure there is some rhym and reason to it. | 15:25 |
| OvenWerks | if acpi can figure it out, it must be standrd somehow | 15:25 |
| OvenWerks | Basically, from what I can tell, one of the many lines of "Pin-ctls: 0x00:" changes it's number | 15:28 |
| OvenWerks | huh, funny the things one finds looking for other things. Turns out my master volume has been turned down to half for months (years?) | 16:12 |
| Eickmeyer | Haha | 16:23 |
| Eickmeyer | OvenWerks: I just got done packaging and testing raysession, it's on its way into autobuilds now. Great alternative to ladish when paired with patchage or carla. | 21:33 |
| studiobot | <teward001> Eickmeyer: You are damn crazy with the number of things needing sponsored now lol | 22:37 |
| studiobot | <teward001> I just got the flood of 20 emails to sponsors xD | 22:37 |
| studiobot | <Eickmeyer> I was told to package as much as possible to get practice in to get access to the ubuntustudio package kit. | 22:38 |
| studiobot | <Eickmeyer> *set | 22:38 |
| studiobot | <teward001> ah indeed. | 22:38 |
| studiobot | <Eickmeyer> @tsimonq2 told me I didn't have enough experience, so this is me getting experience. | 22:38 |
| studiobot | <tsimonq2> @Eickmeyer [@tsimonq2 told me I didn't have enough experience, so this is me getting experie …], This is true. | 22:39 |
| studiobot | <teward001> well I may or may not poke the packages at my convenience | 22:39 |
| studiobot | <teward001> and then tear you new ones lol | 22:39 |
| studiobot | <Eickmeyer> hehe | 22:39 |
| studiobot | <Eickmeyer> @teward001 The flood of emails you just got was actually me removing ubuntustudio as "being affected by" since those were old, old requests. | 22:40 |
| studiobot | <Eickmeyer> Like, several years B.E. | 22:40 |
| studiobot | <teward001> ah heh | 22:41 |
| studiobot | <Eickmeyer> As i look at the sponsorship queue, I have two new packages and an SRU, and one that I merely assisted with getting the process started. | 22:42 |
| studiobot | <Eickmeyer> (one of which @tsimonq2 reset the time-in-queue on, which shoved it to the back of the line after having been in the queue for OVER A MONTH) 😡 | 22:44 |
| OvenWerks | Eickmeyer: good. How does it show on the menu? (reysession) | 23:09 |
| Eickmeyer | OvenWerks: It shows in multimedia for now, but we can throw it in anywhere using ubuntustudio-menu. | 23:10 |
| Eickmeyer | I'd need to add it in the seed and drop ladish. | 23:10 |
| OvenWerks | Sorry, that was not what I meant Eickmeyer. I was meaning does the way it is named in the menu make it obvous what it is? | 23:19 |
| Eickmeyer | OvenWerks: Yes. | 23:19 |
| OvenWerks | When you say multimedia do you mean media playback? | 23:19 |
| Eickmeyer | Yes. | 23:19 |
| * Eickmeyer needs to reboot | 23:19 | |
| OvenWerks | Eww | 23:19 |
| OvenWerks | k | 23:19 |
| OvenWerks | Eickmeyer: when you are back... I have an idea about menus. | 23:21 |
| Eickmeyer | OvenWerks: It looks like it showed-up in "Audio Production" without modification. | 23:23 |
| Eickmeyer | Annnd... go for idea. | 23:23 |
| OvenWerks | Eickmeyer: we have been forcing applications into certain places with hard coding. In the long run this is not good. It does not let the user move an application with menu add for one. and it does not deal with new apps | 23:25 |
| OvenWerks | My though is to take the same apps that we move with the config file and give then an overriding desktop file | 23:26 |
| Eickmeyer | That's actually a great idea, but how do we prevent apps that aren't installed from showing? | 23:26 |
| OvenWerks | Hmm, this would work for our xfce sessions | 23:26 |
| OvenWerks | it may not work for Studio on top of. Could though. | 23:27 |
| OvenWerks | that would be a question for sure | 23:28 |
| Eickmeyer | Honestly, I think making some way to parse/edit what -menu does is the best way. There could be a way to do it on a per-user basis. | 23:28 |
| OvenWerks | We would almost have to have a script that added them and removed them... needs thought | 23:29 |
| OvenWerks | per user goes in .local/share/applications/ | 23:29 |
| OvenWerks | system overrides go in /usr/share/ubuntustudio/applications/ | 23:30 |
| Eickmeyer | Yes, but again, we're running the risk of items showing that aren't actually installed. | 23:31 |
| OvenWerks | a script on startup that goes through the whole bunch checking if the executable exists and adds NOSHOW=True to those it can't find | 23:32 |
| Eickmeyer | That would mean it'd have to run as root. | 23:33 |
| Eickmeyer | So, a systemd service. | 23:33 |
| OvenWerks | Yup, not controled by the user | 23:33 |
| Eickmeyer | How much boot time would be impacted, do you think? | 23:34 |
| OvenWerks | The idea is half baked at best at this point. Just a quick idea I just thought of. Needs much rounding out so probably post 19.10 | 23:35 |
| OvenWerks | boot time should not be impacted at all as systemd runs things in parallel | 23:35 |
| Eickmeyer | Ok. | 23:35 |
| OvenWerks | It just has to depend on all file systems mounted | 23:36 |
| Eickmeyer | Which means multi-user.target, I think. | 23:36 |
| OvenWerks | There is a target for all file systems mounted (not sure what it is called) | 23:37 |
| OvenWerks | but mutiuser would work. The menus do a quick look through all the *.desktop locations every time they are opened so the time should not be that bad. | 23:38 |
| OvenWerks | First check for changes ... mtime on the directory file should cover everything in the directory. | 23:39 |
| sarnold | except changes to files | 23:39 |
| OvenWerks | I think we are looking for added or rermoved files in the directory. | 23:42 |
| OvenWerks | not that it matters at this point, too much else to work on this cycle. | 23:43 |
| sarnold | heh, I'm familiar with that.. | 23:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!