Replies: 5 comments 1 reply
-
|
I like (1), as when in-office, I utilize thunderbolt dock frequently. However, my biggest pain point with the current setup (which is very likely outside of scope for egpu-switcher) is the fact that Xorg session cannot survive the eGPU being unplugged. I already accidentally unplugged from the eGPU station several times and crashed my session as a result. |
Beta Was this translation helpful? Give feedback.
-
|
I wonder if there is some sort of way to keep that from happening, and +1 to the pain points with egpus being beyond simply switching setups. I also find that suspending the laptop with an egpu doesn't work at all. I'm wondering if there's some tool / command that could be added when it's detected that a thunderbolt3 device is disconnected to try to keep X. That said I think any change in display device needs an X restart, so it seems like we might need to wait for wayland or something to support gpu hot-plugging. |
Beta Was this translation helpful? Give feedback.
-
|
I like all of these ideas, and thanks to you for maintaining this project! A re-write in Rust probably be would be at the top of my wishlist. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Michael, first of all thank you for making this tool. And I have to say your approach to communicating your roadmap and asking for feedback is awesome and refreshing, I wish more projects did the same :-) I don't have any strong opinions on the enhancements you listed, I would just point out that if you want to rewrite everything in another language, it would probably be a good idea to do that before the rest or you will run into "Schlemiel the painter" problem (see below) ;-P Shlemiel gets a job as a street painter, painting the dotted lines down the middle of the road. On the first day he takes a can of paint out to the road and finishes 300 yards of the road. “That’s pretty good!” says his boss, “you’re a fast worker!” and pays him a kopeck. The next day Shlemiel only gets 150 yards done. “Well, that’s not nearly as good as yesterday, but you’re still a fast worker. 150 yards is respectable,” and pays him a kopeck. The next day Shlemiel paints 30 yards of the road. “Only 30!” shouts his boss. “That’s unacceptable! On the first day you did ten times that much work! What’s going on?” “I can’t help it,” says Shlemiel. “Every day I get farther and farther away from the paint can!” |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for inviting me to the discussion! e-gpus are a mini-hobby, so this is a fun conversation :) Also thanks for the phenomenal work on egpu-switcher overall: it's a lifesaver.
This would help me, as I have similar issues.
Combined with 1, this would be pretty great. One thing I think other OS's do very well is react to different hardware configurations, and save the preferences so I don't have to re-select them every time. I view this being a hook that will enable that, especially the shell scripts. Once my setup is detected, I can just add a shell script to run xrandr the way I like.
Might be better than 2 in terms of composability. But I do like the fact that it sets the xorg.conf file for me too: that's the biggest painpoint for me right now.
Usability is always a good thing, but I would personally vote against this one. This may further burden you to go figure out what people are doing incorrectly in their setups, and I think debugging their hardware for them.
As a Rust enthusiast, I don't see a strong reason to do it in Rust, but I would also probably do this given the opportunity.
One advantage of doing it in the current repo is that some people may get updates for free, such as Arch users using the git package. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I've been trying to help out a bit recently as your script literally saved me from being forced to switch to Windows. I just now saw this discussion, I hope I'm not too late to give my two cents. First of all, I love the first part of (2), and I think it could probably be integrated into current egpu-switcher as well. Other than that I'm sorry to admit, I'm quite pessimistic regarding the future of egpu-switcher (not the future of egpus in general). As far as I know, GPU hot plugging is a thing in GNOME Mutter (Wayland based), which, in theory, makes egpu-switcher obsolete on those systems. The only thing keeping X11 alive is the until recently abysmal support for Wayland by nvidia, but that's slowly changing. And as more distros are tinkering with Wayland as the default protocol, I think we'll therefore see a decline in the need for egpu-switcher. I admit, it'll take some time for everybody to adopt Wayland, but as soon as the major distros all run some implementation of Wayland (that supports gpu hot plugging) the script will probably become obsolete. That said, I love your idea stated in (1). Configuration tied to different environments is indeed a use case I believe to prevail for some time. Either way you choose, I'd love to help. I've been looking for an excuse to actually learn Rust 😉 |
Beta Was this translation helpful? Give feedback.
-
Hello users of egpu-switcher,
This is my first time using the Discussions tab, so I don't know if that will reach anybody 😄
I'd like to inform you about my plans for the future of egpu-switcher, and the extent in which I'd like to expand its functionality.
As my current idea about the projects future is heavily based on my personal use-cases, it would be great to hear some feedback from the users, contributors and sponsors of egpu-switcher.
The current state of the project
What does egpu-switcher actually do? The main goal of this project is to allow users to use their eGPU on the Linux Desktop without having to tinker around with PCI IDs and Xorg configuration files. Apart from that, the provided systemd service automatically "connects" the eGPU on bootup so users don't need to edit any Xorg configuration files every time they want to switch from using (or not using) their eGPU. That's basically it.
Why would I want to change anything?
I believe that the current functionality is enough for a lot of people, especially those using full-fledged desktop environments, as the DE might already take care of some of the stuff I'll mention below.
So what about people not using a DE, or people that would like to change configurations based on their current environment? By environment I mean:
a) Using the laptop by itself (undocked)
b) Using the laptop connected to an eGPU
c) Using the laptop connected to a thunderbolt docking-station (non eGPU)
I personally use my laptop in all those "environments" and I switch around quite frequently, and the last on the list (c) isn't covered by egpu-switcher. This is bothering me a bit, because there isn't a really easy way (I know of) to change my system configurations based on where I'm working. Whether that's on the couch with the laptop undocked, at my desk with the eGPU or at my office where I have a (non eGPU) docking station with a multi-monitor setup.
What are my ideas for the future?
Instead of just recognizing whether the eGPU is connected, recognize different eGPUs (there might be people having more than one) and recognize "normal" thunderbolt docks, allowing for environment specific configurations without the need to create an environment detection script yourself.
Instead of replacing the whole
xorg.conffile, allowing the user to specify their own99_<dock-uuid>.conf(or similar) file which will then be loaded into/etc/X11/xorg.conf.d, depending on the connected devices. This might allow for more possibilities and a cleaner setup. Also allowing the user to create shell scripts that are executed depending on the environment would allow to have different environment specific configurations even outside of Xorg. (Those are just some ideas, the mentioned specifics might change once more considerations come into play during implementation)If the tool already has the possibility to detect different environments, detecting eGPUs, etc. Why shouldn't it just provide a CLI for other developers to use the eGPU detection in their own programs? This would also help encapsulating this stuff in the source code and probably lead to a better software architecture.
Although more features and more customization might complicate a setup, the tool should stay as user-friendly as possible. The user should be able to "make their eGPU work" on their Linux Desktop without the need to learn about all the stuff mentioned above. There are even some ways to further enhance that. (Automatically detect docks with video device as eGPU, hint the user on how to authorize thunderbolt or possible problematic configurations -> security level set to USB-only?, etc...)
As the project grows, I'd like to change tracks and develop in Rust instead of Bash. I really do like shell scripts for prototyping or smaller tools that are just meant for myself. But as more features come into the project and more people rely on it, bash scripts become a bit more painful to manage.
When is this finished?
I don't have a timeframe, as I'm just working on that project when I have enough free time and motivation to do so. I recently started prototyping some of the stuff above (in Rust) to see how I could achieve those goals. I already found a way to integrate bolt via its DBus interface, which opens up the possibility to recognize all kinds of Thunderbolt devices and even give hints to the user if the device still needs authorization, whether the security-level is too strict, and much more.
I am also not sure if this will be an update to
egpu-switcheror if that should be a separate tool, as the scope of the tool would exceed being "just" anegpu-switcher. Let me know your thoughts about that.Feedback
So what do you think? Is this stuff something that you'd use, or do you know any tools out there that already cover those requirements? I don't necessarily want to reinvent the wheel, so if you already have a good working solution for "switching environments" as I've mentioned above, please let me know.
Looking forward to reading your comments.
Stay safe.
Beta Was this translation helpful? Give feedback.
All reactions