<ppetrov^>
hey guys, are the collections in portdb somehow sscreened for activity? I mean, I see kde4 there, which is for sure quite old and was probably tested on a few releases back
<SiFuh>
ppetrov^: kde4 is an Alan repo. Alan repos are usually quite messy. There is no activity screening that I am aware. Usually when a user doesn't want to manage a repo they just contact jaeger
<SiFuh>
But for Alan's alan repo, he does update a bit. I don't know about the kde4 as I don't use it.
<ppetrov^>
thanks SiFuh
<ppetrov^>
why are alan's repos 'messy'?
<ppetrov^>
i have taken a few ports from him and updated them to the latest
<ppetrov^>
also cpan2crux, a utility that he wrote is what made me switch to CRUX couple of years ago :-P
<SiFuh>
I poach some of his ports too. I just don't think he takes the time and effort to be an obsesively compulsive pedantic perfectionist :-P
<farkuhar>
https://www.mizrahi.com.ve/crux/ports/ Heh, look at the port that was most recently updated (2022-12-24 13:36). I seem to recall this port being involved in the gnupg build errors a few days ago.
<farkuhar>
just a weird coincidence, no real connection between Alan's updating schedule and the opt/gnupg port.
<jaeger>
The official portdb hides repos that it can't access or scrape properly. The unofficial portdb adds a tag pointing out how many times it has failed and when the last successful sync happened. Other than that, no particular activity screening
<farkuhar>
it's been a while since I've had reason to test Firefox WebRTC performance with any audio backend besides pulseaudio/pipewire, but I just got a successful mic check with the sndio backend instead.
<SiFuh>
Cool
<farkuhar>
just reporting for the benefit of OpenBSD fans who like to see their good ideas adopted in Linux.
<SiFuh>
I like sndiod a lot. sndiod_flags="-f rsnd/0 -F rsnd/1 -r 43200 -b2160"
<ukky>
Mic works with ALSA too in Firefox. Just needs some tweaks, depending if Firefox is pre-built binary, or compiled.
<farkuhar>
ukky: it's been my experience that recent versions of Firefox will only give you a drop-down menu of audio devices with the pulseaudio backend. With ALSA and sndio, only the default device is accessible.
<ukky>
I am using apulse, to emulate pulseaudio interface for Firefox, when only ALSA is actually available on the system.
<farkuhar>
but maybe ALSA would get more equal treatment in Firefox if I resurrected the ancient version that shows up in Alan's repo (from the time before the ALSA backend was demoted to Tier-3 or unsupported)
<ukky>
I don't think you can make Firefox to directly interface ALSA in any recent Firefox version. Firefox dropped direct ALSA support, as far as I know.
<farkuhar>
ukky: ah yes, I remember using apulse for exactly that purpose. But after volunteering to maintain the contrib/firefox port, these days I have at my fingertips a build with native ALSA support.
<farkuhar>
unfortunately the native ALSA support does not include the enumeration of devices, which is why I now plan to test whether sndiod environment variables AUDIORECDEVICE and AUDIOPLAYDEVICE are respected in WebRTC apps.
<farkuhar>
I remember being so excited in October 2020 to learn that OpenBSD finally allowed those two environment variables to be set independently, which meant that I could use USB speakers for playback, and a USB webcam for the microphone.
<ukky>
You can configure ALSA to do that via ~/.asoundrc, specifying default playback and recording devices
<farkuhar>
Well in October 2020 my only computer was a laptop running OpenBSD, so I didn't exactly have ALSA to play with. I do remember letting the kernel recompile overnight, and rebooting the next day to enjoy separate devices for playback and recording.
<farkuhar>
But what finally drove me away from OpenBSD was its poor support for my Wacom tablet. I couldn't share handwritten notes very easily while videoconferencing, unless I was willing to dedicate serious desk space for a high-res document camera. Since I already had a secondhand Wacom tablet from a colleague, I switched to the OS that supported it better.
braewoods_ has joined #crux
braewoods has quit [Read error: Connection reset by peer]
<ukky>
Lack of HW support, or too much resource requirements, are probably the reasons why people switch from one OS to the other.
groovy2shoes has quit [Ping timeout: 258 seconds]
groovy2shoes has joined #crux
<farkuhar>
Switching the OS might be overkill, depending on the situation. In the case of drawing tablets, the sensitivity to stylus movement can vary even within a single OS, just by switching the desktop environment or compositor.
<farkuhar>
On OpenBSD in 2020 there wasn't really any freedom to migrate away from Xenocara (to Wayland, for example), and the available X desktop environments did not exhibit much difference in their support for the Wacom tablet.
<farkuhar>
But these days on CRUX, I notice slight differences in the stylus sensitivity, depending on whether I'm running Xorg, sway, or another Wayland compositor. All of them still offer a much smoother experience than what I remember from my days with OpenBSD.
<ukky>
It should be possible to find where stylus sensitivity is set. Then configure it according on runtime environment.
<farkuhar>
Even if the OpenBSD of 2020 had offered more flexibility in the choice of DE, I think the smoothness of tablet input would still be constrained at the kernel level. I don't recall when configuring the OpenBSD kernel back then whether it was possible to enable absolute positioning for specific input devices, which is what you often want in a drawing tablet.
<ukky>
I am not familiar with *BSD. Maybe they are good some other purpose. I have heard it is good for netwoking.
<farkuhar>
The contrast when switching to Linux was obvious, at least in my use case. No matter which DE I logged into, the tablet input was properly handled at the kernel level, resulting in smooth handwritten notes (not the pixellated stuff I was getting when OpenBSD defaulted to the driver for a generic pointing device).
<ukky>
Some users settle for 'good enough', or 'seems working'. But it would be a shame for a developer who would create 'good enough' driver for a HW device. Maybe *BSD emulates your device?
<farkuhar>
No idea about how the driver gets selected in *BSD. I doubt it's the udev rules that I'm familiar with. But after settling down with CRUX, these days I don't have any machines running *BSD, not even a VM. I haven't bothered to go back and see how the OpenBSD drivers have improved in the span of a few years.
braewoods_ has quit [Remote host closed the connection]
ppetrov^ has quit [Quit: Leaving]
<cruxbot>
[core.git/3.7]: rhash: 1.4.3 -> 1.4.4
dani-77 has joined #crux
dani-77 has quit [Client Quit]
<cruxbot>
[contrib.git/3.7]: python3-m2r: added patch to build against mistune0
<ocb>
SiFuh: you're into ghidra iirc?
<SiFuh>
No
<cruxbot>
[core.git/3.7]: cmake: rebuilt for rhash 1.4.4