Mhwd manjaro settings graphics drivers can't install/uninstall

Searching google, coming up empty for the error messages. When I try to uninstall bumblebee, or install prime drivers, it fails, and the window is tiny, so the error message is unreadable.

Changes Failed. Click on show

And, clicking on show error shows nothing useful, because it's a tiny window.

A step by step guide on how to switch from bumblebee to prime would be useful. I'm following along in Guide: Install and configure optimus-manager for hybrid GPU setups (Intel/NVIDIA), and he just clicks remove bumblebee and install prime, and says, "wait for the success message", lol. No success will occur, and there seems to be no troubleshooting on the internet. Maybe my google SERPs are broken, because I can only imagine there are many people with this same problem.

Run the MHWD command from terminal and provide the exact error you get, regardless.

Is still more relevant than a description, but the error from terminal is the most important one.
Also, provide:
inxi -Fxxxza --no-host
mhwd -li

I ended up finding the error message from the terminal, it was dependencies.

Is there anywhere to report bugs for Manjaro?

The windows handling errors and successes for system utilities like manjaro settings need to draw fullsize and be resizable in all the major DEs, and mhwd panel for manjaro settings is absolutely unacceptable. Tiny checkboxes, invisible errors, window not resizable, etc.

You could have shared them here.

Aren't we talking right now about the issue?
If you want, then try to report them on the package page, to the correct subgrup

If are specific Manjaro packages in discussion, you can also report them here

It is resizable in KDE Plasma, XFCE and Gnome. What is the issue on that?

It follows the Qt standards. What makes it unacceptable and by who?

Perfectly visible here. There are no LARGE checkboxes anywhere in any DE themes.


and this is from a VBox install.

You can press Details when you install either a driver or a kernel
That will show the entire process. Is not invisible. Example:
But that is a dialog class window, that can't be resized.

1 Like

So hopefully I reported this in the right spot, but no way to know. I don't want to just "talk about it". I want to submit actual bug reports and have developers triage and fix them. The hardest part about every bug is figuring out which package it belongs to, and which bug tracker system that package's bugs should be reported to. Manjaro doesn't take clear ownership of the problems that happen, which makes a little bit of sense, because it is Arch-based, but it makes no sense not to take ownership when it's something like "Manjaro Settings". Manjaro Settings needs to work near-perfectly, and it's Manjaro's responsibility. It's very likely that whoever reads my bug report will find a way to claim it's someone else's fault, instead of just fixing the problem, which is a problem with the Manjaro experience, not Ubuntu, not Arch, etc, regardless of which package that developer will claim the problem lies within.

It's not resizable on GNOME. You admit the "dialog class" window can't be resized. That's a problem.
Please don't reply to a bug report with "works for me". A core app like this must work well enough for many/most people, or it'd've been fixed ages ago.
Screenshot from 2020-05-08 14-30-12 Screenshot from 2020-05-08 14-29-41 Screenshot from 2020-05-08 14-29-10

You are not reporting on the proper channel in the first place, so is not a bug report at all. Is in #newbies
So, please report the issue here

It "resizes" when i press Show Details, but ... what Qt Style are you using, what theme? If you are using the GTK2 style for Qt, what GTK theme are you using? Could be related. Also make sure you mention the display resolution and scaling factor too in the bug report on gitlab.

See what I mean? I reported it last time we talked on >extra>manjaro-settings-manager, but somehow that's wrong, it should be >manjaro-settings-manager. HTF should regular people know the difference? Good systems just accept bug reports in one place, and then people and software assign them to the appropriate package.

I don't know what Qt Style or theme I'm using, and I shouldn't have to. People should test Manjaro-settings-manager, a core package to the manjaro experience, with a wide variety of display resolutions, scaling factors, Qt styles, and themes, if differences in any of those can produce unusable UIs. I'm sure a developer will claim that the problem isn't with Manjaro-settings-manager, but some combination of the display resolution, scaling factor, Qt styles, and themes I'm using. This is a huge meta-problem. Instead, just own the entire Manjaro experience, and say, wow, it's unacceptable for a core Manjaro package to not work with every display resolution, scaling factor, Qt style, and theme. There should be no combination of those inputs that makes checkboxes tiny, and every window that might contain an error message must be resizable so people can read every error message that comes up.

That is the PKGBUILD page, the issue is not with that, or at least, if needs a new Qt patch is yet not clear from what you "reported" so far.

I'm a regular.

Are you referring to the OS itself or gitlab as a web-based DevOps lifecycle tool that provides a Git-repository manager? Issues on gitlab are not migratory, that is why need to be filled in the proper place, with the proper information.

But you consider is relevant and a demand for the developer to know what you have installed and visually identify it from screenshots...

That is your choice and opinion.

Most forum users do use it, yes, you are the first one to mention theme issues here since 2016 to this date. See here

Developers make no claim when there is no clear data about an issue. Every aspect is important, so they know where to look, then conclude if is dependent of their application or if is something else that affects their application. If they can fix it, they will fix it.

So, in your opinion the developers should own all the displays with all the resolutions, plus have all the themes installed to test? I don't think is reasonable to ask them for that.

According to what standard, the Qt5 or GTK+ ? If you are using the gtk2 theme to decorate Qt applications, there can be inconsistencies. If you use an old Qt theme, there will be issues, quite possible. If you use Kvantum, then there is a totally different way to deal with the assets of the theme. All can be influenced/or not (yet again depending the theme) by the scaling factor of the display, and the resolution.

That feature already exists, but if the UI is not working properly because reasons yet unknown, then of course the error/message windows will fail to render properly.
I will point this topic to the team so they pay extra attention to it, and maybe there will be a followup discussion ar directly a fix for your issue.

1 Like

Do you think an attitude like that makes people more or less willing to help you? :thinking:

If you take the time to read the following two articles, they will give you the insight necessary to have a great experience both as a Linux user and as someone who interacts with various Linux communities online:

1 Like

I don't like Windows. I came from Mac, and I love Linux. The attitude is appropriate, and should have no influence on people "helping" me. People who make linux distros should own their distro's entire experience, not make excuses for why "it would just work if you didn't make xyz choice, or use abc hardware".

Let people report bugs in one place.

If your core package isn't working in any setting that people are likely to choose/encounter, like display resolution, scaling, qt style, theme, fix it. And own that experience.

It is unacceptable for error messages to be unreadable in any combination of qt style, theme, resolution, and scaling.

If that's so, you should really ask for a refund, then. Just speak to the manager.

@bogdancovaciu I think scaling may be issue. I have the qt5ct and qt5 settings apps mentioned in that other user's thread. I can change qt5 theme no problem, and the checkboxes are still tiny, but different colors. I don't find much searching google or this forum for scaling and manjaro settings manager. An old post by dalto just says it's all good in GNOME.

Maybe is worth having a look also at font size. I'll think to a way i can reproduce this, but since i have dual monitor setup at 1920x1080 for me all UI looks fine.

Tried this, no dice.

The discrepancy is only seen on HiDPI screens.

If I knew Qt C++ I would have created a merge request on Gitlab.

There is a couple of issues - including the issue you created

I imagine a huge fraction of manjaro users are running GNOME on hi def screens, 2x scaling, and whatever defaults. I think people just put up with tiny checkboxes and inability to read error messages. I know I did for months.

The install dialog are actually not resizeable.. it is fixed. Yes it "resize" itself when you click on detail but it still so small..(400x160 or 400x260 with details)
Long time ago the dialog itself was resizeable but someone resigned entirely the dialog and decided to make it fixed size.. and way too small (just my thought).

And yes there is some issue with HDPI in MSM.

And the fixed size can have even more impact on HDPI with scaling.. As I'm not sure it will actually change the size of the Dialog but only the elements inside it and make it unbearable as elements inside will be bigger to be readable but in a more tiny dialog

1 Like

I tried setting QT_AUTO_SCREEN_SCALE_FACTOR=1 and QT_AUTO_SCREEN_SCALE_FACTOR=2. Neither has any effect. I did this by 'export' in my terminal. Should this fix the problem?

Looks like Qt::AA_EnableHighDpiScaling is to be put in the settings app by developers, not by me, but if there's a way I can do it, let me know.

PKGBUILD is out of date on gitlab (many others are too .. this needs work)
So cannot use makepkg to build/install due to icu dep (requires old version).

But it should be in /src/msm/main.cpp in early lines (starting at #31)

int main( int argc, char* argv[] )
    MsmApplication app( argc, argv );

Is just the one addition.

Might also need this below


And in one of the issues philm mentions maybe need to import this above:

    from PyQt5.QtCore import Qt, QCoreApplication

Not sure what is being recommended. I am somewhat familiar with C, C++. Are you suggesting I compile my own manjaro-settings app? Can't we just report this as a bug in the appropriate place, and fix it for everyone at once? It should only affect people with High DPI, and it should only affect them positively, forcing the app to honor gnome's settings, right?

Forum kindly sponsored by