[-] jrgd@lemm.ee 11 points 1 day ago

I believe it's mostly drawing tablet support in Qt and in turn porting to Qt6 that's holding native Wayland builds back.

[-] jrgd@lemm.ee 6 points 6 days ago* (last edited 6 days ago)

A good amount of distros actively have this functionality. To avoid breaking system packages, you can install the distro package for the given module or as the error recommends: use a venv for the given project.

As to why many guides don't include it, I suspect as typical for many Linux-centric articles: they weren't been written by knowledgeable individuals or just in general are writing with knowledge that is often 5+ years out of date.

[-] jrgd@lemm.ee 18 points 2 weeks ago

For the most part, you won't be able to escape Unix-like paradigms when using Unix-like systems. Notably, users have to exist in some form. You don't necessarily need to give them passwords for the frontend signage, but they need to exist. The shortlist of setting up cage would be:

It's not quite a few clicks, but this can in contrast also be fully automated trivially if it's something you need to setup more than once.

[-] jrgd@lemm.ee 41 points 2 weeks ago

In what way does Windows fulfill a 'kiosk' display mode better than Linux for you? Are you looking for permanent installations or just temporary lockdown to a single application. One of the more modern and straightforward methods currently is using cage.

Cage lets you spawn a Wayland compositor from command-line (or via system service, obviously) that launches either a singular or multiple exclusively-fullscreen applications.

5
submitted 2 weeks ago* (last edited 2 weeks ago) by jrgd@lemm.ee to c/techsupport@lemmy.world

A bit of basic information beforehand that should be relevant:

  • OS: Fedora 40 (x86_64)
  • Desktop: KDE Plasma 6.1.3 (5.27.x -> current) (Wayland)
  • Motherboard: ASUS PRIME X470-PRO
  • Primary keyboard: Keychron S1 (tested on stock firmware, Windows layers)

The issue in some more detail: alt-tabbing windows in KDE sometimes leaves behind an alt keypress in the window that was alt-tabbed from that won't go away until alt is registered as pressed again by the window.

This has certainly been an interesting issue that has been a problem for at least a year at this point. I've finally gone in to do basic troubleshooting regarding the issue. I have pretty much ruled out hardware at this point. Originally, I had my primary keyboard plugged into my monitor's USB hub. In testing, I tried another keyboard, migrated the connect to my motherboard rather the monitor's USB hub, and the alternate keyboard plugged into the motherboard. All tests eventually result in the same issue happening over time.

One thing I see as a potential pattern but cannot fully confirm is that it appears these remnants of alt keypresses only show up in XWayland windows, and not native Wayland applications. Applications I have seen it occur in include Minecraft Java Edition, various Proton games, Electron applications that don't enable native Wayland support (e.g. Discord), Steam. This issue also occurs less if I allow XWayland apps to always see modifier keypresses. Though I assume this is more from the tendency to alt-tab back into affected windows, registering another alt keypress.

At this point, I am pretty confident this is software-related, but I cannot find any existing bug reports within the past three years (especially noting any relevant to KDE) that describe this problem. I am unsure of how one would go to debug this category of issue or even find the root cause component that is causing the issue. I am curious if anyone here has also had this irritating quirk occur and/or if you know any workarounds/fixes for this given problem.

[-] jrgd@lemm.ee 27 points 3 weeks ago

A key list of compatible/incompatible components to look for:

  • GPU
  • Network Interfaces (Ethernet and Wi-Fi)
  • Audio Interfaces (not that much of an issue anymore)
  • Disks
  • Motherboards
  • CPU (excluding x86 ecosystem)
  • Peripherals

The explanations for this are pretty long, but are meant to be fairly exhaustive in order to catch most if any pitfalls one could possibly encounter.

GPU:

A big one is the choice between AMD, Intel, and NVidia. I am going to leave out Intel for compute as I know little about the state it is in. For desktop and gaming usage, go with AMD or Intel. NVidia is better than it used to be, but still lags behind in proper Wayland support and the lack of in-tree kernel drivers still makes it more cumbersome to install and update on many distros whereas using an AMD or Intel GPU is fairly effortless.

For compute, NVidia is still the optimal choice for Blender, Resolve, and LLM. Though that isn't to say that modern AMD cards don't work with these tasks. For Blender and Davinci Resolve, you can get them to use RDNA+ AMD cards through ROCm + HIP, without requiring the proprietary AMD drivers. For resolve especially, there is some serious setup involved, but is made easier through this flatpak for resolve and this flatpak for rocm runtime. ML tasks depend on the software used. For instance, Pytorch has alternate versions that can make use of ROCm instead of CUDA. Tools depending on Pytorch will often have you change the Pytorch source or you may have to manually patch in the ROCm Pytorch for the tool to work correctly on an AMD card.

Additionally, I don't have performance benchmarks, but I would have to guess all of these tasks aren't as performant if compared to closely equivalent NVidia hardware currently.

Network Interfaces:

One section of hardware I don't see brought up much is NICs (including the ones on the motherboard). Not all NICs play as nicely as others. Typically I will recommend getting Ethernet and Wireless network interfaces from Intel and Qualcomm over others like Realtek, Broadcom, Ralink/Mediatek. Many Realtek and Mediatek NICs are hit-or-miss and a majority of Broadcom NICs I have seen are just garbage. I have not tested AMD+Mediatek's collaboration Wi-Fi cards so I can't say how well they work.

Bluetooth also generally sits into this category as well. Bluetooth provided by a reputable PCIe/M.2 wireless card is often much more reliable than most of the Realtek, Broadcom, Mediatek USB dongles.

Audio Interfaces:

This one isn't as much of a problem as it used to be. For a lot of cards that worked but had many quirks using PulseAudio (a wide variety of Realtek on-board chipsets mainly), they tend to work just fine with Pipewire. For external audio interfaces: if it is compliant to spec, it likely works just fine. Avoid those that require proprietary drivers to function.

Disks:

Hard drives and SSDs are mostly fine. I would personally avoid general cheap-quality SSDs and those manufactured by Samsung. A lot of various SATA drives have various issues, though I haven't seen many new products from reputable companies actually releasing with broken behavior as documented by the kernel. If you wish to take a detailed look of devices the kernel has restricted broken functionality on, here is the list.

Additionally, drives may be one component beside the motherboard where you might actually see firmware updates for the product. Many vendors only release EXE files for Windows to update device firmware, but many nicer vendors actually publish to the LVFS. You can search if a vendor/device is supplied firmware here.

Motherboards:

In particular, motherboards are included mainly because they have audio chipsets and network interfaces soldered and/or socketed to them. Like disks, motherboards may or may not have firmware updates available in LVFS. However, most motherboard manufacturers allow for updating the BIOS via USB stick. Some laptops I have seen only publish EXE files to do so. For most desktop boards however, one should be able to always update the motherboard BIOS fine from a Linux PC.

Some motherboards have quirky Secure Boot behavior that denies them being able to work on a Linux machine. Additionally some boards (mostly on laptops again) have either broken or adjustable power state modes. Those with adjustable allow for switching between Windows and standard-compliant modes.

Besides getting a Framework laptop 'Chromebook edition', I don't think there is much you will find for modern boards supporting coreboot or libreboot.

CPUs:

For your use case, this doesn't really matter. Pretty much every modern x86 CPU will work fine on Linux. One only has to hunt for device support if you are running on ARM or RiscV. Not every kernel supports every ARM or RiscV CPU or SoC.

Peripherals:

Obviously one of the biggest factors for many new users switching to Linux is their existing peripherals that require proprietary software on Windows missing functionality or not working on Linux. Some peripherals have been reverse engineered to work on Linux (see Piper, ckb-next, OpenRazer, StreamController, OpenRGB).

Some peripherals like printers may just not work on Linux or may even work better than they ever did on Windows. For problematic printers, there is a helpful megalist on ArchWiki.

For any other peripherals, it's best to just do a quick search to see if anyone else has used it and if problems have occurred.

[-] jrgd@lemm.ee 17 points 4 weeks ago

For multi-monitor: use Wayland. For 2.5Gbps Ethernet NICs, they never work properly on any system in regard to performance, but I presume you are referencing the subpar Realtek NICs not connecting? Depending on the distro, you likely won't have the driver and/or firmware package preinstalled to make it work.

24
submitted 1 month ago by jrgd@lemm.ee to c/foss@beehaw.org

Greetings,

For several years, I have used the wonderful Cantata as a frontend to MPD. Sadly, the frontend stopped receiving updates in 2022 and has started to some problems with age. While I continue to use Cantata for as long as I can, I have been looking around at other music players. However, I haven't seen anything that aims to implement some of the nice things from Cantata.

In short, a few things I have been looking for in a player:

  • suitable for playing single songs, albums, full artists, custom mixes, or playlists (no hyperfocus)
  • can either set a custom artist sort tag (albumartist, composer, etc.) or properly handle semicolons (or some other separator char) in tags
  • semicolon tag split in general would be nice for genre handling
  • powerful active queue handling (move; shuffle and sort by song, album, artist; remove duplicates; consume on play; etc)
  • online lyrics search from multiple providers

Additionally, some nice-to-haves that Cantata handles:

  • CD ripping
  • export library to portable device (with compatibility)

Anyone have a favorite that can handle at least the shortlist of functionality I come to expect? I don't expect specifically a frontend for MPD, but I would prefer a player that doesn't struggle to handle a library with 10^4^ magnitude library size.

88
submitted 3 months ago by jrgd@lemm.ee to c/linux_gaming@lemmy.ml

cross-posted from: https://lemm.ee/post/38676431

A while back I ended up getting tired of making hacks to get custom binaries to launch in Steam for Windows titles. Primarily for modding, I would find a way to simply launch custom EXE files through Steam to ensure the modding tools and the game were contained neatly in the same prefix. My first ventures with this were Skyrim and Fallout: New Vegas. With these titles, I overrode the gamebryo/creation engine launcher EXE with Mod Organizer 2 (renamed to be the launcher). While this worked, the solution doesn't work for other games without a secondary launcher that is targeted through Steam.

I eventually came to the conclusion that one can override launch targets entirely in Steam, and that tools like SteamTinkerLaunch could take advantage of this. However, STL certainly does a lot and honestly, that is way more than I really desired just to launch games with a custom EXE. Thus I made a shell script that essentially allows for the user to write in their own custom target and have it launch right through Steam.

The usage for this is simple. Just copy the 'shim' file into the game directory, override the Steam launch arguments to include "./shim %command%", and all is good. Furthermore, environment variables (such as DRI_PRIME=1), additional launch wrappers (gamemoderun), and game launch arguments (-novid for Source Engine titles) all work. If one needed a combination of all of this, it would look something like "DRI_PRIME=1 gamemoderun ./shim %command% -novid".

The way target editing currently works is on first launch the shim file grabs the default game target and writes it as the contents of 'target', another file in the game directory. From there, one can simply edit the target location in the file and shim will launch the custom executable.

So far, I have used this to get things like RaftModLoader and BeamMP working (mod loader for Raft and multiplayer for BeamNG.Drive respectively). I see no issue with this being able to also work for Bethesda titles and others that need custom executables. As I understand as well, the actual game install directories on a Steam Deck with SteamOS are mutable, and with a bit of tinkering through desktop mode should help get a seamless experience for launching modded Steam games for Deck users as well.

I hope someone finds as much use and utility that I have for getting a lot of modding tools for Windows games working without needing to mangle the prefix using protontricks in some cases or install the absolute multi-tool that is SteamTinkerLaunch.

153
submitted 3 months ago by jrgd@lemm.ee to c/linux_gaming@lemmy.world

A while back I ended up getting tired of making hacks to get custom binaries to launch in Steam for Windows titles. Primarily for modding, I would find a way to simply launch custom EXE files through Steam to ensure the modding tools and the game were contained neatly in the same prefix. My first ventures with this were Skyrim and Fallout: New Vegas. With these titles, I overrode the gamebryo/creation engine launcher EXE with Mod Organizer 2 (renamed to be the launcher). While this worked, the solution doesn't work for other games without a secondary launcher that is targeted through Steam.

I eventually came to the conclusion that one can override launch targets entirely in Steam, and that tools like SteamTinkerLaunch could take advantage of this. However, STL certainly does a lot and honestly, that is way more than I really desired just to launch games with a custom EXE. Thus I made a shell script that essentially allows for the user to write in their own custom target and have it launch right through Steam.

The usage for this is simple. Just copy the 'shim' file into the game directory, override the Steam launch arguments to include "./shim %command%", and all is good. Furthermore, environment variables (such as DRI_PRIME=1), additional launch wrappers (gamemoderun), and game launch arguments (-novid for Source Engine titles) all work. If one needed a combination of all of this, it would look something like "DRI_PRIME=1 gamemoderun ./shim %command% -novid".

The way target editing currently works is on first launch the shim file grabs the default game target and writes it as the contents of 'target', another file in the game directory. From there, one can simply edit the target location in the file and shim will launch the custom executable.

So far, I have used this to get things like RaftModLoader and BeamMP working (mod loader for Raft and multiplayer for BeamNG.Drive respectively). I see no issue with this being able to also work for Bethesda titles and others that need custom executables. As I understand as well, the actual game install directories on a Steam Deck with SteamOS are mutable, and with a bit of tinkering through desktop mode should help get a seamless experience for launching modded Steam games for Deck users as well.

I hope someone finds as much use and utility that I have for getting a lot of modding tools for Windows games working without needing to mangle the prefix using protontricks in some cases or install the absolute multi-tool that is SteamTinkerLaunch.

[-] jrgd@lemm.ee 20 points 3 months ago

https://librewolf.net/

A summary from its site and known technical details:

  • no telemetry by default
  • includes uBlock Origin
  • has sane privacy-respecting defaults
  • prepackages arkenfox user.js
  • relatively well-maintained fork of Firefox that keeps up with upstream
  • No major controversies AFAIK

As for Windows 7, nobody should really need to install Librewolf anyway on such a device. No device running Windows 7 should have access to the internet at this point. If you are asking about compatibility intending this use case, you have bigger problems to worry about than your choice of browser. If you just need to view HTML files graphically, even Internet Explorer or an older firefox ESR will do.

[-] jrgd@lemm.ee 36 points 5 months ago

The heated bed is coupled to a thermistor. I'd argue controlling the temperature in order to not accidentally overheat parts of the phone is a step above a hair dryer.

[-] jrgd@lemm.ee 25 points 6 months ago

For the longest time reading this post, I didn't catch that you were setting up a simple dual boot for an internal SSD and thought with using tools like Ventoy you were making a multiboot portable install.

You are obscenely overcomplicating this. Your current approach is almost completely wrong to getting a functional multiboot system that passes secure boot and everything else.

Quite literally, bootstrapping from windows can use Rufus or ventoy on a USB stick to dump the ISOs on. Then boot into bios from the USB EFI entry. From there, simply install Fedora (no VM necessary). You'll get Fedora installed in a GPT/EFI configuration (if you formatted your drive for install). If doing manual partitioning to leave space or do other configurations, format the drive to GPT. If multibooting, you may want to expand your EFI partition beyond 512MiB for multiple distros.

For other Linux OS to install alongside, you can then install them in the free space. Another comment mentioned to not install a bootloader on the secondary OS(es), which is generally a good idea.

For Tails, it is not meant to be installed on an SSD. It is best to use it on a flash drive.

Overall, a majority of your issues stem from the following:

  • trying to use live distro images as an actual OS install
  • using Ventoy as your bootloader
  • using legacy MBR partition tables instead of GPT without expressed need for them
  • Using virtualbox in general to provision bare metal hardware (changes need to be made in your VM software of choice to get EFI booting to work)

I'd argue your conclusion of people not switching to Linux because you found it too hard is almost entirely not because of any issue on Linux, but the factors you wedged yourself into on a modern x86 PC due to your methods in accomplishing your goal.

[-] jrgd@lemm.ee 51 points 8 months ago* (last edited 8 months ago)

One can comfortably use NTFS to read and write files on modern Linux distributions, but NTFS in general is not very suitable for running applications on or using for long-term usage between a dual-boot. Windows can and will often lock up NTFS partitions whenever it decides to hibernate rather than shutdown or sometimes suspend. NTFS while not being the greatest FS in general will also have worse performance on Linux than Windows. You can totally keep data stores on a Linux system, though you won't be able to make use of many of the advanced features some Linux/BSD-oriented filesystems offer. You can totally keep your drives as they are now, though if you intend to make a full switch you should consider migrating your drives' data over to more Linux-oriented filesystems (be it Btrfs, Xfs, or Ext4 is your choice depending on the features you want). In short, NTFS works but lacks a lot of features and performance that a more suitable filesystem would offer.

[-] jrgd@lemm.ee 18 points 9 months ago

Not the same person, but I greatly enjoy my (now second) Pebble classic for several reasons, which I imagine some are shared between Starayo.

  • Always-on Display
  • Week-long battery life
  • High contrast display that can be read easily in low light as well as in direct sunlight
  • Simple notifications support, with quick canned replies
  • physical button navigation that make the watch easy to use without needing to look at it
  • Isn't obscenely large
  • quick launch application shortcuts from holding side buttons
  • simple media playback control that is responsive
  • Doesn't attempt to be another smartphone, but rather as a local companion to your existing smartphone (doesn't thrive on individual apps, but rather companion apps to complement smartphone usage)
  • Customizable and relatively simple to write applications and watchfaces for.

Unfortunately for me, fossil's watches do not match up. Looking at the gen 6, still uses an ill-suited AMOLED display that is bound to have poor contrast in direct sunlight unless the brightness is cranked so far that it will blow through the battery. Even then, the average battery life on the gen 6 is atrocious compared to most Pebble models as many reports say it can make it through one day. I'm sure by now, WearOS devices have worked out some of the kinks to make them easier and faster to use, though I am not sold on needing a personal assistant in order to do basic tasks (as Fossil markets their gen 6 smartwatch; I do doubt that this is necessary for general function).

Also, this might be controversial, but I personally feel that a device that has Bluetooth and is intended to communicate with a device that is often within ten feet of it really doesn't need to waste resources and probably become more of a privacy nightmare by including Wi-Fi, LTE, and other data communication methods (beside NFC). Furthermore, pretty much every WearOS device I have seen has had a struggle to keep battery life for more than a couple days, and everyone deems that devices that can should be praised for whatever reason. Seeing as my ancient smartwatch that does most of what these newer watches do yet can effortlessly hold a six day battery life at worst, I seriously question why newer watches that have so much compromise and are incredibly misguided as to what a complementary wearable should be are what are being developed. Not to mention that the Pebble classic on launch was $99 USD whereas one can easily find $400+ smartwatches that still have way too much compromise in comparison.

[-] jrgd@lemm.ee 92 points 10 months ago

VideoLabs is made up of many of the same contributors of VideoLAN, including Jean-Baptiste Kempf themself. It is arguable that this is in fact Unity banning VideoLAN's VLC bridges for media playback in Unity.

view more: next ›

jrgd

joined 10 months ago