[02:33] <OvenWerks> Eickmeyer: in the controls package there seem to be some links do not get installed.
[02:34] <OvenWerks> Eickmeyer: ln -s $(DESTDIR)$(LIBDIR)/systemd/system/studio-system.service \
[02:34] <OvenWerks> 		$(DESTDIR)$(LIBDIR)/systemd/system/multi-user.target.wants/studio-system.service
[02:34] <OvenWerks> this link does not seem to be there
[02:36] <OvenWerks> And so cpu governor and boost setting does not work over a boot
[02:38] <OvenWerks> Eickmeyer: /lib/systemd/system/studio-system.service seems to get installed but not linked into multi-user.target.wants
[03:41] <Eickmeyer> OvenWerks: That's weird. I know there's one item in not-installed that was Fedora-specific.
[03:43] <Eickmeyer> OvenWerks: That systemd service file is for Fedora, not for Ubuntu.
[03:45] <Eickmeyer> OvenWerks: autojack is run by the user for Ubuntu. This is because On-Demand isn't a thing in non-Ubuntu systems.
[03:46] <Eickmeyer> OvenWerks: Basically, /usr/lib/systemd/system/studio-system.service is inconsequential to Ubuntu systems.
[03:52] <Eickmeyer> OvenWerks: You'll see from this commit that it was a file I created for non-Ubuntu systems: https://github.com/ovenwerks/studio-controls/commit/307cc3198644ea4bcea1281ff330a898eaab30e2
[03:53] <Eickmeyer> The CPU governor boost setting should be getting set by the reading of the autojack.conf file when studio.service is activated by systemd.
[03:53] <Eickmeyer> Under the user profile.
[03:53] <Eickmeyer> There's a polkit file that keeps it from asking for a password.
[03:54] <Eickmeyer> If it's not working on your system, something else is interfering. I know on my system there are Kubuntu Focus-specific scripts that keep it from interfering because we make that for the hardware specifically.
[03:55] <Eickmeyer> Rather, the Kfocus scripts interfere because they're for the hardware specifically.
[03:56] <Eickmeyer> I know I had to put studio-system.service in not-installed on the AA's request.
[04:02] <OvenWerks> Eickmeyer: ubuntu seems to have followed fedora...
[04:02] <Eickmeyer> is ondemand no longer a thing?
[04:02] <OvenWerks> nope
[04:02] <OvenWerks> that part is for older systems
[04:04] <Eickmeyer> I see it's not even there in Focal?
[04:05] <Eickmeyer> Got removed from under our noses.
[04:05] <OvenWerks> I have been using 20.04 for my daily drive till a few months ago
[04:06] <Eickmeyer> I have a Focal system, stand by...
[04:06] <OvenWerks> in other news it seems I was missusing .which so I will be uploading a fix
[04:06] <Eickmeyer> Ohhh yeah, good idea.
[04:09] <Eickmeyer> OvenWerks: ondemand.service was still a thing on Focal, apparently. With this, we would have to stop supporting studio-controls on Focal.
[04:09] <Eickmeyer> Or rather, not upload new versions to Backports.
[04:10] <Eickmeyer> (I was planning on freezing the Backports for Focal once Jammy releases anyhow, so probably no big deal).
[04:27] <Eickmeyer> OvenWerks: I've got a fix in the packaging ready to go. It removes the ondemand stuff, installs studio-system.service, and enables it. It disables it upon uninstall too.
[04:40] <OvenWerks> ok, i will have the other fix soonish
[04:41] <Eickmeyer> OvenWerks: Ok, in that case are we looking at 2.2.10 or are we full-seinding to 2.3.0?
[04:42] <OvenWerks> we can 2.3 it
[04:42] <Eickmeyer> Ok, bet.
[14:56] <OvenWerks> Eickmeyer: ok 2.3.0 is out
[14:57] <OvenWerks> Eickmeyer: in other news... try /etc/init.d/rtirq start and then /etc/init.d/rtirq status
[14:58] <OvenWerks> something doesn't work. I am guessing that may be the reason I have less stability at 16/2 than in 20/04
[15:14] <OvenWerks> using sudo htop does not allow higher priority either
[17:24] <Eickmeyer> OvenWerks: My guess is because it's still using /etc/init.d instead of being a proper systemd service. For me it seems to be working fine after running those commands as sudo.
[17:28] <Eickmeyer> In other news, 2.3 is uploaded.
[17:29] <OvenWerks> Thank you... can't dl it yet but soon I guess
[17:39] <Eickmeyer> Usually takes a couple hours to pass autopkgtests and what-not.
[18:01] <OvenWerks> Eickmeyer: back to rtirq... all my audio devices used to show up in ps ax as [irq/*] they do not any more.
[18:02] <OvenWerks> they don't show up at all
[18:03] <Eickmeyer> OvenWerks: Yeah, that's very odd. I'm seeing no issue on my system (two snd_hda devices, rest are USB)
[18:04] <Eickmeyer> Bear in mind, rtirq is ancient and hasn't been updated since 2015.
[18:05] <OvenWerks> that is ok. I am just wondering about the change in irq drivers in the newer kernel.
[18:08] <Eickmeyer> And that could be a thing too. I know there's a lot of work around PREEMPT_RT.
[18:08] <Eickmeyer> The details about which I'm very fuzzy.
[18:10] <OvenWerks> normally for me jackd would show up as priority higher than 50 as well.
[18:11] <OvenWerks> maybe ALSA has changed to fit PW
[18:20] <OvenWerks> 21.10 with 5.13 is still ok. So either 5.14 or 5.15 something has changed
[18:23] <Eickmeyer> Likely.
[19:33] <OvenWerks> kernels are already up to 5.15.11 so maybe it has been fixed post 5.15.0
[20:31] <OvenWerks> Eickmeyer: I had to add threadirqs to the kernel command line. I thought that was set by default in lowlatency
[20:51] <Eickmeyer> OvenWerks: It is. I inserted it into your code that you made for grub.d
[20:52] <OvenWerks> huh, I had to add it in /etc/default/grub
[20:53] <Eickmeyer> Weird. I see it in my /boot/grub/grub.cfg.
[20:53] <Eickmeyer> OvenWerks: Ohhhhhh yeah, it's hardcoded. You don't need to add it there.
[20:53] <Eickmeyer> That'll have the effect of adding it twice.
[20:54] <OvenWerks> may not be hard coded any more
[20:54] <Eickmeyer> But, when you boot, go to any lowlatency kernel and edit the command, you'll see it's there.
[20:57] <OvenWerks> Ah, I am not running this as the main parition.
[20:57] <OvenWerks> That is probably why
[20:58] <Eickmeyer> That would 100% be why. :D
[21:00] <OvenWerks> I don't know if I can... I will try though I don't install a separate /boot partition for efi
[21:03] <Eickmeyer> Well, you don't have to, but at the same time the EFI has to be mounted to /boot/efi as a FAT32 partition.
[21:04] <OvenWerks> it isn't now
[21:04]  * OvenWerks didn't make one and just did install anyway
[21:05] <Eickmeyer> Yeah, if one's already available it'll just use it.
[21:05] <Eickmeyer> If not, it'll create one.
[21:05] <Eickmeyer> But the mount point has to be there.
[21:05] <Eickmeyer> A check of lsblk will show you.
[21:06] <OvenWerks> I have swap, / and /home/extra
[21:07] <Eickmeyer> That sounds to me like you're running in MBR mode, aka non-EFI.
[21:08] <OvenWerks> yes, that was what I said
[21:09] <OvenWerks> I have lots of partitions that depend on that
[21:10] <Eickmeyer> Yeah, that's fine. If it's working then you're good.
[21:12] <OvenWerks> The installer really wanted me to create a small directory for efi but I refused. So it won't boot to this from the top, I have to go down the list.
[21:14] <Eickmeyer> Ah, I see.
[21:14] <Eickmeyer> The installer is supposed to auto detect whether or not it's on EFI, but I think that was an upstream bug in Camamares that only recently got fixed. Like, in the past week.
[21:21] <OvenWerks> The system can do efi, but the disk is older.
[21:40] <Eickmeyer> Yeah, you likely are running an MBR disk on an EFI system.
[21:40] <Eickmeyer> If you were to reformat the disk, you'd want to reformat it as GPT in order to take advantage of EFI.
[21:41] <OvenWerks> The system can be set up either way. What are the advantages?
[21:52] <Eickmeyer> OvenWerks: EFI contains more security since an actor can't simply overwrite the first couple blocks of the drive (the Master Boot Record) to install malware.