Sebastian Krzyszkowiak @dos@librem.one

#perfect #shotonlibrem5

🍃 miętowy smak dobrych dni #perfect #shotonlibrem5

🚂 choo choo #perfect #shotonlibrem5

@aeva This one is as @glyph said - I'm not aware of an API for that. It smells like it could be a reasonable addition to propose, perhaps as part of xdg-output - which happens to be where you get all the info needed to always render at 1:1 density, by the way.

Meanwhile, you could ask the user to touch the screen first and lay your surfaces out based on that, I guess?

Also, there's no magic there. If it got fullscreened, something made it fullscreen and you'll be able to trace that.

@aeva @glyph You call set_fullscreen(output) on your surface and it goes fullscreen on selected output.

If you use some middleware to do that for you, then you need to spend some effort to find out how to do the equivalent there. You can use WAYLAND_DEBUG=client to inspect what calls it ends up making below your code.

@glyph @aeva No, this is the fullscreen *shell*, not something you use on desktops.

However, the regular xdg-shell's xdg_toplevel::set_fullscreen simply takes a wl_output as a parameter. It's not a Wayland's problem at all.

https://wayland.app/protocols/xdg-shell#xdg_toplevel:request:set_fullscreen

@stfn W tę stronę to żaden problem; gorzej, gdy trzeba ciąć 😜

@ridge BTW. Photos from Librem 5 look more like this:
https://social.librem.one/@dos/114035748117789854
https://social.librem.one/@dos/114541817150368216
https://social.librem.one/@dos/114941740757004551
https://social.librem.one/@dos/114540898853088761

It's not that hard to get there once the sensor works, but it requires some domain knowledge and the community is too small to just have enough people with it around. Lots of low hanging fruits there across devices.

@ridge It looks like demosaicing with incorrect pixel order, bad white balance and no color calibration. Just make the same mistakes to recreate it anywhere you want ;)

@janvlug @cpontvieux @fraggle You need to load a different kernel module, the default one expects a battery with integrated coulomb counter. This will also affect the LED (it isn't hardware controlled). SHR Settings should let you do that with a button press, but don't get mad at 16yo me if it doesn't work reliably 😁

@rail @mgorny https://media.ccc.de/v/38c3-what-s-inside-my-train-ticket

@attie > Okay, so is it a USB C alt mode? (e.g: DP) ... almost certainly no, because it also has USB A ports.

It almost certainly is DisplayPort alt-mode, especially with that 4K@30Hz cap that matches the available bandwidth on 2 lanes of DP1.2 which you get when sharing the lanes with USB 3 ports.

@pavel It looks off - I'm afraid this is effectively an upscaled 524x778 stream. Your yuyv function throws half of the horizontal resolution away by duplicating the pixels' luminosity (and that's in addition to regular chroma subsampling that will happen there, which wouldn't be as noticeable on its own).

@grzeeesiek @stfn Gęściej niż u mnie SKM/KM 🥺

@pavel Indeed: https://gitlab.gnome.org/World/Phosh/phoc/-/merge_requests/706

@kpcyrd @cwebber @dpk Even without these clauses the outcome would likely be similar in western jurisdictions if a hostile takeover was attempted, but there's of course no way to know for sure without actually having a court decide (at which point it's already costing you time, effort and money), so every bit of reassurance/deterrence helps anyway 😁