<samueldr>
generally you'll have to figure out how to get I²C going through your display driver
<samueldr>
looks like boot.kernelModules = [ "i2c-dev" ]; was the only thing needed
<bqv>
Whoops, my home directory got garbage collected
<bqv>
samueldr: all monitors?
<samueldr>
probably not
<samueldr>
though I need to test more, a TV (not a monitor) fails here
<samueldr>
but I had success with I believe 4 different brands and models of actual monitors
<elvishjerricco>
samueldr: There's also `ddcci-driver-linux`, which has a driver for a `/sys/class/backlight` device for ddcci monitors
<elvishjerricco>
`kernelPackages.ddcci-driver` on nixos
<samueldr>
yeah, forgot about that one, couldn't remember what difference it had too off the top of my head
<samueldr>
though ddcutil can also be used to tweak other settings!
<elvishjerricco>
The tools you linked require root privileges
<samueldr>
you could (ab)use it as a screen-yellowifier like redshift does
<samueldr>
just as much as writing to /sys/ does
<elvishjerricco>
samueldr: Well backlight devices can be used without root privileges, no?
<samueldr>
since you could give the proper files the proper rights so those tools can talk to the displays
<samueldr>
I don't think so "raw", but what there is is more tools and wrappers ready to work with them
<elvishjerricco>
Otherwise how would my desktop be changing the brightness?
<samueldr>
and X11 is kind of helping too sometimes
<samueldr>
it all depends on how your desktop does it
<elvishjerricco>
Hm. I thought backlight control was kinda a standard protocol or something
disasm has quit [Ping timeout: 256 seconds]
<samueldr>
kind of yeah, through /sys/class/backlight generally AFAIUI
<samueldr>
which in turn often use a helper utility to manage
<elvishjerricco>
Anyway apparently there's potential resource conflicts if you attempt to use i2c-dev with ddcci-driver-linux at the same time
<samueldr>
that's plausible
<elvishjerricco>
That's according to the arch wiki
<samueldr>
I wonder if ddcci-driver could expose the other values
<elvishjerricco>
So who knows :P
<samueldr>
(or if it already does)
<samueldr>
because the same still applies, that you could control other things
<samueldr>
like on my main monitor I control the input!
<elvishjerricco>
I know it's two different kernel modules
<elvishjerricco>
ddcci and ddcci_backlight
<elvishjerricco>
So I'm guessing ddcci does more
<samueldr>
so I have this wrapper around ddcutil which I use to switch to hdmi, or switch to dp
<samueldr>
depending
<elvishjerricco>
Huh, neat
<samueldr>
and a neat thing, probably not universal, the display responds do DDC commands even if the output is not the current one
<sphalerite>
samueldr: where do you get these modules? I've been using ddcutil, but wishing there were a kernel driver
<sphalerite>
oh, found it
<sphalerite>
why isn't it upstream :(
waleee-cl has joined #nixos-chat
bqv has quit [Quit: WeeChat 2.9]
bqv has joined #nixos-chat
bqv has quit [Quit: WeeChat 2.9]
bqv has joined #nixos-chat
<bqv>
Gentlemen
<bqv>
I have no root
xd1le has quit [Quit: Quit]
<bqv>
Wait
<bqv>
Huh, it didn't take…
bqv has quit [Quit: WeeChat 2.9]
bqv has joined #nixos-chat
bqv has quit [Client Quit]
bqv has joined #nixos-chat
<bqv>
There we go, thats a bit better
<bqv>
Now I have no root
<bqv>
So, root was easy, cause nixos. /home and /var are another story, I guess thats where impermanence might help
parsley936 has joined #nixos-chat
disasm has joined #nixos-chat
polezaivsani has joined #nixos-chat
<talyz>
bqv: That's the idea, at least :)
<infinisil>
Ah yes, calling my local taxes department because I have a question:
<infinisil>
I
<infinisil>
I explain my situation for a couple minutes when she interrupts me: "No need to explain everything, I'm not actually the person you're looking for, maybe try again on monday"
<infinisil>
The heck
<lassulus>
its friday afternoon, nobody is working anymore
<infinisil>
Ugh
<infinisil>
Well that just fueled my anxiety
<Valodim>
evening security personnel up for a jest
<eyJhb>
infinisil: that seems weird
<eyJhb>
Then fucking redirect me to someone that can help me :.
<eyJhb>
Just a rand(0,1000) > 10; then # not right person code
<eyJhb>
bqv: nothing mounted at /?
<pie_>
this <eyJhb> Then fucking redirect me to someone that can help me :.
<pie_>
i guess i usually try to get around this by starting off with "hi i have questions about _. Did I call the right place? Who do I talk to?"
CodeSpelunker has quit [Ping timeout: 256 seconds]
<bqv>
eyJhb: tmpfs p
rajivr has quit [Quit: Connection closed for inactivity]
kalbasit_ has quit [Ping timeout: 240 seconds]
<energizer>
if i log in through a desktop manager like lightdm should that be able to unlock my keychain too? currently i have to type my password twice
<worldofpeace>
energizer: if it's gnome-keyring and your keyring was created when that feature was corrected then yes
<Mic92>
sphalerite: cgroups are also commonly used to track child processes
<Mic92>
this is how systemd solves this problem
<sphalerite>
energizer: replacing the current process with the new program, rather than forking a child
<sphalerite>
Mic92: ah, so you can do something similar to kill(-1) but with a narrower scope there?
<Mic92>
sphalerite: yes, because every child will be also in the cgroup.
<sphalerite>
energizer: so usually when you type a command in a shell, like cat, the shell will use the fork() system call (or clone typically on modern linuxes, but that's a minor detail), which creates a new process which is almost an exact copy of itself
<sphalerite>
energizer: then the child will use the exec system call to replace itself with a different program
<sphalerite>
energizer: the `exec` command makes it skip the fork
<sphalerite>
energizer: so you no longer have a parent bash, only the zsh
<samueldr>
it replaces the current process
<Mic92>
It replaces the process image to be precise
<samueldr>
(that's not a shell feature, you can do it in your programs too where it matters)
<energizer>
ok cool that's what i thought
<philipp[m]>
So what you can do is run `bash` in bash, or `zsh` in zsh. Then kill it. You keep your shell. When you do it with exec, your terminal will close.
<energizer>
i'm trying to do `NIX_SSHOPTS='PATH=~/.nix-profile/bin ~/bin/proot -b ~/nix:/nix exec zsh' nix copy` but setting the PATH seems to be failing " can't open input file: nix-store"
<sphalerite>
oh wow that's sneaky
<sphalerite>
maybe try with env
<sphalerite>
so env PATH=~/.nix-profile/bin …
<sphalerite>
actually no that probably won't help
MichaelRaskin has quit [Ping timeout: 260 seconds]
<energizer>
er part of the problem is exec is a builtin right
<energizer>
so proot can't run it
<sphalerite>
since the shell will interpret the command
<sphalerite>
aah yes
<sphalerite>
you want to exec ~/bin/proot
<energizer>
.nix-profile/bin/zsh: can't open input file: nix-store
<energizer>
env is a good idea, not sure what's wrong
<sphalerite>
aah the problem is that zsh will try to execute what you pass to it as a script
<sphalerite>
try… '… zsh -c 'eval "$@"'
<sphalerite>
this is some nasty trickery, but I kind of like it x)
<energizer>
i'm not sure how to quote that since i'm already in '
* colemickens
whispers something about it being blink-only-compatible :P
<joepie91>
(it's written in the context of Electron but mostly the same applies here)
<joepie91>
(and no, I did not write that)
<colemickens>
joepie91: with regards to that doc, do you have thoughts about Flutter / have you tried it?
<bqv>
yikes
<joepie91>
colemickens: I know of its existence. it being a Google thing significantly reduces my interest in considering it, and AFAIK it is a rather opinionated UI toolkit which is another reason I wouldn't want to deal with it :)
<samueldr>
all opinions are bad, except mine
<samueldr>
;)
<bqv>
i didn't even say anything!
<samueldr>
oh, I was reacting to "opinionated"
<colemickens>
lol
<joepie91>
it basically hasn't cleared my "does this look like a viable use of my time" bar yet
<bqv>
oh, lol
<joepie91>
(background: I try to make code write-once-useful-forever, which means that shaky non-trivially-replaceable foundations are extremely uninteresting to me)
* colemickens
nods
<joepie91>
colemickens: also, more broadly about UI frameworks - despite all the shit that the DOM (partly deservedly) gets, it's the only viable low-level UI management API I know of, ie. the only one that allows incremental innovation in UI handling tech without having to rewrite the world every time
<bqv>
not that i remotely want to argue about this, but using nix would mean you could write in a ...less divisive framework, and still be guaranteed reproducibility in the future
<bqv>
nah, nevermind, i really don't want to talk about this
<joepie91>
pretty much every other UI thing is a lot more opinionated, having a specific model of applying updates that you cannot opt out of or replace, for example
<joepie91>
and it is only divisive when people make an issue out of it :)
<joepie91>
bqv: I am not talking about reproducibility
<colemickens>
joepie91: hm, I think I kind of get it. I assume you like Web Components, then. (you saw MS's fast.design thing?)
<joepie91>
colemickens: not at all, Web Components are a complexity nightmare and really not a very good spec at all
<samueldr>
weird, nix already allows joepie91 to implement it in whatever joepie91 desires; without making the end-user do any work about that
<joepie91>
also very opinionated
<colemickens>
oh, huh, okay :P
<joepie91>
colemickens: so this is somewhat oversimplified, but not by much: people used to write raw DOM manipulation code, then it was slightly improved with stuff like Backbone to at least tie it to model updates, then Angular happened and we suddenly had a serious (though not very well-engineered) UI framework for building real applications and doing actual state management
<joepie91>
and it completely missed all the innovations that happened after that
<joepie91>
that is approximately the point where the rumbling about Web Components started, and WC basically try to implement that model that Angular had, But Native(tm)
<joepie91>
and then there was a bunch of retroactive patching of things to try to not be completely behind the times and somewhere around there I lost track
<colemickens>
is that circa-Polymer-era?
<joepie91>
all that seems left now is a highly-opinionated, overly-complex, difficult-to-make-performant and difficult-to-work-with component API, where it's really not clear that it should have ever become a core thing at all
<joepie91>
because it very much feels like a UI library vendored into a browser
<joepie91>
colemickens: Polymer was, I think, the first experimental webcomponents implementation
<joepie91>
somewhat developed in tandem
<joepie91>
and Polymer was an improvement over Angular, but that's about the most positive thing I can say about it
<joepie91>
in practice, the state-of-the-art UI management approach right now is JSX/React
<joepie91>
because the ecosystem moved on despite the endless delays with web components
<joepie91>
(that's not to say that JSX will forever remain the state-of-the-art, it will very likely be improved upon by something else in the future, which is precisely why I don't like opinionated UI APIs - those prevent that innovation from happening, in a field that very much still needs it)
Jackneill has quit [Ping timeout: 264 seconds]
<joepie91>
I really need to write an article about the API inflation in JS-land, at some point...
kalbasit has quit [Ping timeout: 246 seconds]
Jackneill has joined #nixos-chat
parsley936 has quit [Remote host closed the connection]