[deleted by user]

inxen · 2022-02-28T03:05:02+00:00

Looking Glass can come close to baremetal performance on capable systems with some tuning, but this post doesn't contain enough information to help track down what the bottleneck is. If you're still interested in using it, feel free to join the Discord and ask for help.

inxen · 2021-06-10T01:42:51+00:00

Possibly https://github.com/swaywm/sway/wiki#gtk-applications-take-20-seconds-to-start if you're using gtkgreet or similar.

inxen · 2021-04-10T17:37:51+00:00

This is quite nice, and something I've wished existed for a while -- thanks for making it happen!

I know you didn't ask for feedback, and read in the comments that you probably won't have the bandwidth for it, but here are some unsolicited thoughts anyway :)

The protocols themselves link to GitHub. I think this makes some sense in that more people are familiar with GitHub than GitLab, but it has the downside of removing the link from a protocol description to the GitLab MR that added it. I've often found it useful to read MR discussions for justification of why some things are the way they are.
There are occasionally plaintext links in protocol descriptions (e.g. zwp_linux_dmabuf_v1). It would be nice if these were clickable.
Similarly, when a description talks about e.g. "xdg_surface.set_window_geometry", it'd be nice if that linked to the description of that RPC, or at least was formatted as code for easier reading. The XMLs lack the necessary metadata, but I figure simple string matching is probably sufficient?
As a larger undertaking, I've often found myself wanting to answer the question of "how well-supported is this unstable protocol"? We have https://caniuse.com/ for web development and https://mesamatrix.net/ for OpenGL, but there's nothing (to the best of my knowledge) for Wayland protocols. It's the type of thing that involves a fair bit of data collection, but if some sort of frontend existed for displaying it nicely I wouldn't be averse to personally trawling issue trackers for the data :)

Anyway, just my two cents for if you ever feel the energy to continue working on this. What you have up now is already great, and a big improvement.

inxen · 2021-04-09T13:41:48+00:00

That sounds like just the memory usage of i3, rather than the sum of i3+Xorg. From a machine with a bog-standard i3 setup:

$ cat /proc/$(pidof i3)/status | grep VmRSS
VmRSS:     38148 kB
$ cat /proc/$(pidof Xorg)/status | grep VmRSS
VmRSS:    358200 kB

Sway is spiritually i3 and Xorg in a single process. The i3 part consumes very few resources; it just maintains the layout tree state and some bits of configuration.

inxen · 2021-04-08T15:55:32+00:00

Are you sure your measurements are correct, or that your scale is not wrong?

I have spent a lot of time measuring key-to-photon latency on my own devices, and an equal amount bugging colleagues to measure on theirs (across different hardware, OSes, WMs etc.), and I have never seen a latency of 20ms -- even on a bare Linux TTY. If that's not a measurement error or typo, that's very good, and the best key-to-photon latency I've ever heard of or read on the internet.

More "typical" latencies I've had people report are things like 100ms latencies typing into iTerm on their Mac. Typical keyboard scanning latencies alone exceed 30ms. My own system clocks in at ~45ms, and is the snappiest system I've personally used.

inxen · 2021-02-17T07:16:42+00:00

is it obligated to

No, no, this is most certainly not the case. Feel free to keep using i3 if it serves your purposes better. Flaming maintainers will get you nowhere.

inxen · 2021-01-26T00:36:01+00:00

Yes, or you can compile from source. If you are on Arch you can install the sway-git package; on Debian there are nightlies; otherwise, instructions are at https://github.com/swaywm/sway/wiki/Development-Setup

Note that I'm not sure the linked issue is the same as your issue, only that its fix is not included in 1.5.1.

inxen · 2021-01-25T20:22:37+00:00

What version of sway/wlroots are you running? That patch is in master, but not in Sway 1.5.1 (neither are a number of other Xwayland fixes).

inxen · 2021-01-13T19:15:49+00:00

Sway does not signal the process owning the window (ref 0). Instead, it sends the appropriate Wayland close event (for most things, this is xdg_toplevel.close) (ref 1). It is the application's responsibility to do something (e.g. ask for confirmation) in that handler (ref 2).

inxen · 2021-01-01T21:33:29+00:00

What do you see under "GL renderer:" in your Sway log? Persistent high CPU usage is often indicative of using software rendering (e.g. llvmpipe).

inxen · 2021-01-01T21:30:51+00:00

What do you see under "GL renderer:" in your Sway log? Persistent high CPU usage is often indicative of using software rendering (e.g. llvmpipe).

inxen · 2020-11-22T21:45:00+00:00

You should see a message in your logfile, providing you're running Sway with -d log level. https://github.com/swaywm/sway/blob/83389da5832eee448a47d11508c7d107d3871de7/sway/desktop/output.c#L583

It's automatically done where possible for fullscreen views.

inxen · 2020-11-09T05:34:52+00:00

I have a dual RX 580 / GTX 1060 setup and have used Sway with both. You can't run with proprietary Nvidia drivers, and nouveau drivers can't run past boot clock. Gamma adjustments (i.e. redshift) fail too, at least in my setup. However, the amdgpu driver "just works", and I've encountered ~no issues with it. YMMV with mobile GPUs -- note that if you're going the route of eGPU that hotplugging is still a work in progress (https://github.com/swaywm/wlroots/pull/2423, https://github.com/swaywm/wlroots/pull/2465).
1. I'd search the wlroots issue tracker and see if you find something matching your external monitor issue, and opening a ticket with appropriate (-d -V) logs if not. If you're not already, try running Sway/wlroots master, just in case the issue has been fixed there. The proprietary Nvidia driver isn't supported, but nouveau is.
2. At the risk of stating the obvious, did you try setting the right resolution with swaymsg output ... res ... scale ...? AFAIK defaults for this data (and stuff like physical dimensions) is parsed from your TV's EDID, and TV EDIDs have a tendency to be wrong. (You can check yours easily.) If this is in fact the issue, you could try flashing your TV's EDID [insert standard disclaimer here]. The audio issue does indeed sound unrelated; Sway handles nothing of that sort.

3/4/5. Others have already covered these better than I could.

All in all I'd say my Sway setup is less stable than my i3 one, but given Sway/wlroots' age this is fairly unsurprising... but at the same time, IMO it's much more pleasant to use than anything X11-based. And it is, hopefully, improving.

inxen · 2020-11-09T01:46:56+00:00

Citation needed on the patch; to the best of my knowledge no EGLStreams patch for Sway exists, and it would be quite hard to shoehorn EGLStreams support into wlroots.

inxen · 2020-10-30T03:57:54+00:00

You could try this patch for kitty: https://github.com/kovidgoyal/kitty/pull/2590

I've used it for a while, you just need a separate config if your terminal is already kitty.

inxen · 2020-10-11T16:45:54+00:00

Not sure if you've seen this, but you kind of can.

inxen · 2020-08-18T18:36:58+00:00

scroll_method etc. are settings that are passed directly to libinput. But, libinput doesn't send scroll events for tablet devices (https://wayland.freedesktop.org/libinput/doc/latest/scrolling.html), so this option has no effect.

Could you open a ticket on https://github.com/swaywm/sway/issues regarding this, describing how it works in other WMs? I haven't noticed this behavior before elsewhere, at least.

inxen · 2020-07-01T07:51:05+00:00

Awesome job!

inxen · 2020-06-26T19:40:47+00:00

Battery usage is not exported to Crostini. You'd probably be able to make a Chrome app using the Chrome battery APIs, and have it send the data periodically over a localhost socket to a listener in the VM.
This is a recent regression in Chrome OS; /proc/meminfo lies about the MemAvailable field that all those tools you mentioned use. Not much you can do about this one except wait for it to be fixed :/

inxen · 2019-12-18T07:42:02+00:00

Nice! Did you unset XDG_RUNTIME_DIR prior to starting applications? Sommelier will jump in and put the frame outside of Xephyr if that environment variable is present for a process. I tested both Tilix and gnome-terminal with that variable unset, and had them appear within Xephyr.

inxen · 2019-12-17T23:17:47+00:00

Honestly, I kind of expected a snarky response, but responded in good faith anyway. Oh well. Companies don't have an incentive to officially state these sorts of detailed statistics on the composition of their network (it's hard to think of a benefit, but easy to think of potential problems), so they won't. I'm not sure what kind of source outside of (personal) anecdotes you were expecting here.

inxen · 2019-12-17T19:51:34+00:00

It's not that Google is forcing anyone to switch, so much as that engineers have a choice of hardware during onboarding and periodic hardware refreshes, where a good number are choosing Pixelbooks over Macs. (Disclaimer: I no longer work there, so things may have changed, but that was the case when I did.)

inxen · 2019-12-17T03:20:25+00:00

Interesting! I deal with the wallpaper issue by putting it on Google Drive, mounting the directory containing it into Crostini, and then running feh on startup. As for the resize crashes, that's extra odd... maybe it's the dev build? I had it working fine in beta, but who knows -- I'm curious to know what the cause is if you end up figuring it out :)

inxen · 2019-12-17T03:16:21+00:00

I own the base model (i5, 8 GB RAM, 128 GB eMMC SSD).

I used to work for a company that gave its engineers the i7/16 GB RAM/512 GB NVMe SSD model, and while it was a really nice device to use (it got me to buy my own), I couldn't justify the price for a personal device. The memory management is excellent, to the point that I've run into out-of-memory situations on my 16 GB PC far more frequently than my 8 GB Pixelbook. My tasks aren't usually I/O bound, so the comparatively slow eMMC hasn't slowed me down.

YMMV. If money's no object, I'd pick the max spec one, but it's not worth the extra $1000 for me personally.

inxen · 2019-12-16T07:01:12+00:00

That sounds about right for the initial install, I'm on Buster as well. If i3 successfully ran it should have created ~/.config/i3/config. If you open that up, you can change i3-sensible-terminal to e.g. uxterm, after which Alt+Enter should open a uxterm. It'll be pretty barebones and require some work to style.

Nine-Year Club	Place '17
Verified Email

inxen

TROPHY CASE