<f_>
ConanKudo: should I make a new blogpost about 0.2 or you think it's not needed?
<f_>
(hopefully by tomorrow I'll fully recover...)
<dramforever[m]1>
i was thinking about that earlier, do you want a post for every release?
grufwub has quit [Remote host closed the connection]
grufwub has joined #wayback
<dramforever[m]1>
checks git log
<dramforever[m]1>
you know maybe i can write a 0.2 announcement
<ConanKudo[m]1>
either we have a releases page on the website that lists each release announcement like wayland.fd.o does, or we decide to just point people to the GitLab releases page
<ConanKudo[m]1>
I don't care that much one way or another, but we should pick something and be consistent
<dramforever[m]1>
i think we drop releases on gitlab and link to the releases page on the site
<dramforever[m]1>
no need to write a news page every time
<dramforever[m]1>
i wonder if we can get a bot to auto-update the home page to say what the latest version is or something
<ConanKudo[m]1>
well releases on gitlab will happen one way or another, since that's how I tag the release
<dramforever[m]1>
can we make like a bot that sends a MR on every tag to the site repo to change a line in the home page
<ConanKudo[m]1>
if you're thinking of stuff like that, you might as well not have release information at all on the website and just point to GitLab releases for people to check
<hiya>
is it for me?
<ConanKudo[m]1>
hiya: no, for dramforever
<hiya>
ConanKudo[m]1: sorry for the confusion
<dramforever[m]1>
<ConanKudo[m]1> if you're thinking of stuff like that, you might as well not have release information at all on the website and just point to GitLab releases for people to check
<dramforever[m]1>
yeah that makes sense
<dramforever[m]1>
"Wayback is not a fork of Xorg and does not claim its legacy" i like how i just said that and it's now in a newsletter
<dramforever[m]1>
it's not wrong
<ConanKudo[m]1>
well technically it does claim its legacy
<ConanKudo[m]1>
Xwayland is Xorg
<ConanKudo[m]1>
it's literally Xorg with most of the hw/ folder emptied out
<ConanKudo[m]1>
thinking that it is otherwise is disingenuous
tgirl_ has joined #wayback
tgirl has quit [Ping timeout: 240 seconds]
tgirl_ is now known as tgirl
<dramforever[m]1>
i mean, that's xwayland right
<dramforever[m]1>
we're not xwayland
<dramforever[m]1>
we run xwayland
_whitelogger has joined #wayback
pinskia has joined #wayback
norwoodites has quit [Ping timeout: 252 seconds]
pinskia has quit [Read error: Connection reset by peer]
pinskia has joined #wayback
pinskia has quit [Read error: Connection reset by peer]
pinskia has joined #wayback
caskd has quit [Ping timeout: 252 seconds]
caskd has joined #wayback
caskd has quit [Ping timeout: 248 seconds]
caskd has joined #wayback
caskd has quit [Ping timeout: 260 seconds]
caskd has joined #wayback
caskd has quit [Ping timeout: 276 seconds]
caskd has joined #wayback
mojo_x has joined #wayback
tgirl has left #wayback [#wayback]
mojo_x has quit [Ping timeout: 252 seconds]
<bigmac>
hiya: Great read, thank you
<hiya>
bigmac: there is an audio version too :)
<f_>
ConanKudo dramforever - I think it's good to write some news posts every now and then showing our progress
<f_>
Even if it's a tiny post
<ConanKudo[m]1>
then we need something in the site hierarchy to list them
<f_>
wayback.fd.o/news ?
<f_>
Or, well, the list at the bottom of the homepage
<ConanKudo[m]1>
f_: news works
<ConanKudo[m]1>
the bottom of the page should only have the latest entry
<f_>
I mean /news is already a thing
<f_>
Ok I'll make it so the homepage only shows the latest entry later
<ConanKudo[m]1>
f_: it's not in the navigation bar at the top
<bigmac>
It was reported in #25 that, while running a x11 wm from within a wayback session, high refresh rate modes are not present in the output of xrandr and can not be set. I am observing the same, with xrandr modes for XWAYLAND0 going just to 60 fps. However, in contrary to the discussion about the issue in this channel, I run programs within the x11 wm at 120 FPS even with having a secondary 75 Hz
<bigmac>
monitor plugged in. I find that strange, because the programs *utilize* the high refresh rate, but xrandr does not list it as an option?
<bigmac>
I suppose information about refresh rates should come from libxcvt? At least that's what I am seeing used in xserverhw/xwayland.. I still don't understand how can xrandr, seemingly depending on that, list a different active mode than what the applications actually utilize
axtlos has quit [Ping timeout: 272 seconds]
<ConanKudo[m]1>
bigmac: because the xrandr data is not real
<ConanKudo[m]1>
bigmac: in order for it to be real data, xwayland will need to be modified to offer it
jvvv has quit [Quit: WeeChat 4.7.0]
Consolatis[m]1 has quit [Quit: Idle timeout reached: 172800s]
mojo_x has joined #wayback
prabuanand has joined #wayback
<prabuanand>
hiya, i think the article https://nixsanctuary.com/nixsanctuary-bulletin-issue-0/ uses the word "infamous" wrongly for Alpine Linux. It means "well known for some bad quality or deed". I think you meant "not famous" here
prabuanand has quit [Quit: Client closed]
<bigmac>
ConanKudo[m]1: I don't think there needs to be real data. Considering the desktop runs with the expected refresh currently. I *think* this should just be mentioned somewhere. The bigger issue is that one seemingly can't change the refresh rate with the expected tools (running x11 wm, expecting xrandr to just work). Should we have something similar to for example sway has, utility to do modesets
<bigmac>
from the xwayland session?
Consolatis[m]1 has joined #wayback
<Consolatis[m]1>
IMHO the proper (tm) solution to things like xrandr or redshift is to implement wlr-output-management-unstable-v1 and wlr-gamma-control-unstable-v1 respectively in xwayland
<Consolatis[m]1>
+ maybe wlr-output-power-management-unstable-v1 for dpms
<dramforever[m]1>
the main problem is now we have nothing
<ConanKudo[m]1>
no wlr protocol will be ever implemented in xwayland
<ConanKudo[m]1>
if you want it there, the decomposition of wlr-output-management into separate protocols for ext needs to be finished
<ConanKudo[m]1>
and that's based on the assumption that it'll get in, which I'm not sure it would
<Consolatis[m]1>
no objections to that from my side :)
<ConanKudo[m]1>
I don't think any of that is going to happen anytime soon
<Consolatis[m]1>
it doesn't really matter though, unless a xrandr backend can be implemented by a random X11 client (which I doubt) then it requires changes to xwayland so it can talk to the wayland-compositor so it can in turn change the resolution / refresh rate / screen layout
<bigmac>
dramforever[m]1: What do you think of what I wrote regarding sway. Would it not go against the minimalism wayback strives for?
<bigmac>
at least to some extent
<Consolatis[m]1>
if some kind of custom IPC for modesets is considered it might be easier to expose some "wayback" wayland socket to the X11 session (but still not set WAYLAND_DISPLAY) and then use wlr-randr. That approach has the benefit that also other tools like kanshi or wdisplays would work
<Consolatis[m]1>
if that approach is fine as an intermediate stopgap measure to allow for display configuration until there is a proper solution in Xwayland which reacts to xrandr calls I could do some prototype to implement support in wayland-compositor. I don't want to spend the time on that if it doesn't fit into wayback conceptionally though
<bigmac>
I would be interested in following the development of it Consolatis[m]1 as I myself would not know where to start with it at all.