Not anymore. That machine's purpose in life currently is to run BOINC helping search for cures for COVID, AIDS, Cancer, etc. When Solus broke NVidia support I dutifully reported the issue. Next day I paid $10 to download Elementary and it has been running that ever since. Elementary is one of the few distros that actually tests with NVidia before they release.

Can you please let us know which Nvidia driver you have installed?

I had this issue *all the time*, so usually I'd disable xorg screen blanking when using gamepad. This should be bug report to xorg project and not solus.

ok , i understand , thanks for your time :)

@supernova874 That is because this test has concluded, and after the initial update to 5.15 and following revert to 5.14 because of the issues experienced with the former, the release number for the linux-current package in the repository is now higher than the one for these testing packages (210 vs 207), and thus the test package gets replaced on every sudo eopkg up
There will be new packages built if and when another test is scheduled.

I tried installing the 5.15.5-207 on my second "test" pc and after the next update (eopkg up) it downgraded to 5.14.21 . Did i do something wrong? , installed just the kernel and the bbswitch , but same think...

I am encountering the same issue on a GTX 1660S on a desktop with no iGPU on the processor. When I try to boot into Solus from USB, my display detects no more connection and goes black. I still hear the opening sound effect play and can open terminal from keyboard to run speaker-test, so I know it has to be an issue with the GPU compatibility.

Regarding the printer and apologizing for my poor English I wanted to correct my previous message. In fact, although the printer sometimes disappears, other times it works perfectly without drivers (drvless.ppd) (like network printer in my case) .
CUPSDriverlessPrinting
So, as far as I can understans, although sometimes it disappears, maybe you don't need a driver, but I just need to configure CUPS better.
Thanks.

Hello! I'd like to request the printer driver for the Brother printer/scanner: MFC-9140CDN (https://support.brother.com/g/b/downloadlist.aspx?c=eu_ot&lang=en&prod=mfc9140cdn_eu_as_cn&os=128#SelectLanguageType-625_0_1)

If you still needs some testing done ahead of the 5.15.5 rollout, I'd be glad to oblige.

Thanks for your report. Please file this upstream with the Intel graphics team so they can best review your issue. I would suggest providing the information reported via inxi -CGxx though, as well as the kernel you are using uname -a, as that will provide more meaningful information that the videos and screenshot of the hardware info, although the videos will be useful for them in visualizing your issue.

{F8537747}
More Video for Reference!

Memory : 3.7 GiB
Processor : Intel® Core™ i3-7130U CPU @ 2.70GHz × 4
Graphics : Mesa Intel® HD Graphics 620 (KBL GT2)

Need some actual hardware information here.

Hello, I would like to request the printer driver for my Brother DCP 7055W please.

In T10006#190526, @JoshStrobl wrote:

Given the IgnoreABI works, going to mark this as resolved and push it. Thanks for the testing folks.

Booting fine on my system with:

linux-current-5.15.5
nvidia-390-glx-driver-32bit
nvidia-390-glx-driver-common
nvidia-390-glx-driver-current
nvidia-390-glx-driver-modaliases
virtualbox-common
virtualbox-current

Hey folks, sorry for the delay. IRL stuff came up related to searching / interviews / assignment for a full-time job, so had to put all this on the backburner.

Just tested 5.15.1 on my laptop (Tiger Lake with Iris Xe) with no issues on Solus Budgie. Hard drive is LVM and encrypted.

@darkben The change that should hopefully fix the issue you were seeing has merged. Would you be able to test it out? Let us know if you still see issues.

besides simpledrm? (I'm holding out hope!)

@ReillyBrogan

sudo systemctl status lighdm

I think for now it would be fine to simply change the corresponding parts of our package script to

@brent, just to rule out a potential timing issue between the Nvidia modules and lightdm, could you run the following in a tty after lightdm fails to start: sudo systemctl restart lightdm

Just a heads up for folks, going to be cooking 5.15.2 and module rebuilds sometime today (tomorrow, got busy). Will follow-up and update all the links when it is sorted. Thanks for all the testing done so far (I appreciate you all taking the risk and dogfooding the kernel), it's good to hear that aside from some outliers (poor @brent), the changes done in the configuration for SIMPLEDRM have worked. I might try building with SIMPLEDRM off and FB_SIMPLE on after 5.15.2+rebuilds as well to see if that sorts it for individuals using 390.xx (assuming 5.15.2 doesn't).

@Staudey , @livingsilver94
After looking at the README.md at https://github.com/thesofproject/sof-bin, the upstream maintainers recommend moving certain files leftover from installations < 1.7 to a backup directory. Has Solus done this kind of thing in the past, and if so, what's a recommended directory path? It looks like the cp commands in the package.yml should be replaced with mv. We should also clean up files that were installed incorrectly to the wrong directory. After this is decided it should be easy enough to change the install directory to the correct place.

sorry for the wait.

That's interesting. Xorg is complaining about not having the kernel module loaded but there's no error loading the kernel module in the earlier boot log you grabbed.

In T10006#190024, @ReillyBrogan wrote:

@brent Once you get that log and upload it can you please try the following?

Create the file /etc/X11/30-nvidia-tmp.conf and paste in the following contents:

Section "ServerFlags"
  Option "IgnoreABI" "true"
EndSection

And then reboot back into the 5.15.1 kernel and let us know if that helps. (if it does then your issue is the same one described here)

2. Wait a minute or so
3. Log into a TTY (if you're not already dropped at one due to the failure of lightdm to start you should be able to switch to one with CTRL+ALT+F3)
4. cd /var/log
5. ls -ahl
6. Figure out which of the Xorg log files has the newest timestamp (should be within a minute or two of your current time)
7. cp NewestFileName ~/Downloads/
8. Reboot back into a working kernel and then pull the log file out of your downloads folder and upload it

@ReillyBrogan
gotcha. day just ended will post all info tomorrow. I apologize for not furnishing what you need yet. I seem to be the only one on this thread (save harvey at 50% success) at failure. It's possible I am an anomalous outlier, but hopefully clearer tomorrow.

@brent Once you get that log and upload it can you please try the following?

! In T10006#190021, @brent wrote:

followed this precisely. the xorg.1.log is dated one year ago (maybe it has hidden attributes?)
the xorg.0.log is dated minutes ago. attached are both

guess I made a mistale will try 1,log again{F8406636}

In T10006#190016, @JoshStrobl wrote:

@brent Could you try booting into the kernel, let it fail for a bit, restart your PC, boot into the working kernel, and provide /var/log/Xorg.1.log? Need more info since the only thing indicating an issue there is lightdm failing.

@JoshStrobl sorry I didn't notice your comment.

If it helps, this is what I do to get the driver's work (Sorry for the "sof for dummies" instructions, but I document everything I do and once it works I stick with it. I don't have enough knowledge to optimize).

@brent Could you try booting into the kernel, let it fail for a bit, restart your PC, boot into the working kernel, and provide /var/log/Xorg.1.log? Need more info since the only thing indicating an issue there is lightdm failing.

I'll take a look at this in the next few days. My laptop does have an Intel audio device. I don't have any errors but I can look at the folder issue.

No problem.

In T10006#190011, @brent wrote:

Can I uninstall :
sudo eopkg install https://joshuastrobl.com/5.15-testing/linux-current-5.15.1-206-1-x86_64.eopkg
sudo eopkg install https://joshuastrobl.com/5.15-testing/nvidia-glx-driver-32bit-470.82.00-414-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/nvidia-glx-driver-common-470.82.00-414-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/nvidia-glx-driver-current-470.82.00-414-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/nvidia-glx-driver-modaliases-470.82.00-414-1-x86_64.eopkg??

Or does anyone have any suggestions? Thanks

System:
I have Intel i5-4460 + GeForce GT 430 + the repo 390 driver.
stable repo, no luks, no encyption
Packages from this thread installed:

In T10006#189995, @brent wrote:

I have Intel i5-4460 + GeForce GT 430 + the repo 390 driver.
I was going to do the new kernel/470/broadcom test.
Quick question first: what's the glx 470? Is that the new 390? Or something for computers newer than mine?
That's all, thanks,

I have Intel i5-4460 + GeForce GT 430 + the repo 390 driver.
I was going to do the new kernel/470/broadcom test.
Quick question first: what's the glx 470? Is that the new 390? Or something for computers newer than mine?
That's all, thanks,

D12252 reg SDDM issues

@Harvey I'm seeing reports of that for SDDM due to the lack of early KMS for NVIDIA, which means the hardware sometimes is not initialized before sddm starts. There was a similar issue related to amdgpu / radeon initialization that was causing GDM to have issues. Fortunately this seems to be unrelated to Linux 5.15.x. Unfortunately we cannot enable early KMS on NVIDIA hardware as it may negatively impact the use of NVIDIA proprietary graphics.

I had issues but not the ones you expected to find. The system had difficulty booting with 50-70% of the boots I did being unsuccessful, booting to a blank screen and being unable to switch to a TTY.

I managed to mount an NTFS partition. I uninstalled ntfs-3g beforehand.

Hi, I cant that any of the testing refered but Im using the 5.15.1 kernel + nvidia beta driver all seems fine, I also switched to unstable bcs it was asking for mesa version which wasnt in shannon I did that then switched back to shannon :)

@darkness I modified the package. Do sudo eopkg dc (deletes cache) and re-run the installation command for the kernel (shouldn't need it for anything else). Assuming you don't see anything reporting [cached] it should be pulling down the new build. Lemme know if that does it for you and I'll mess with it more tomorrow if it doesn't.

@ReillyBrogan Yes, I know...I stated this in the OP.

FWIW: booting fine in very stock Solus Budgie VM running on VMware ESXi 6.5 w/no fs encryption.

@JoshStrobl I just extracted the 5.15.1 initrd and it doesn't appear that the simpledrm module is actually being included. I would expect to see it at /lib/modules/5.15.1-206.current/kernel/drivers/gpu/drm/tiny/simpledrm.ko but it is not present which most likely explains why it isn't working for @darkness (why it's working for me is still a giant ? but that's irrelevant). It most likely just needs to be added to the dracut --add-drivers flag.

In T10006#189941, @joebonrichie wrote:

I wonder if nvidia-drm.modeset=1 has anything to do with it. Although that flag still has to be set manually iirc.

FWIW : booting fine in virtualbox / no fs encryption

Just tested the new NTFS support and read+write work without issues. No LUKS to test on my end, unfortunately.

I wonder if nvidia-drm.modeset=1 has anything to do with it. Although that flag still has to be set manually iirc.

It doesn't work for me unfortunately. I get no prompt for LUKS, but it does continue booting after entering the passphrase.

My work laptop with Nvidia graphics (Nvidia-only, not hybrid) and LUKS encryption booted successfully and properly displayed the encryption password prompt. Seems like SIMPLE_DRM is working at least in my case.

Is this with or without proprietary graphics?

In T10006#189934, @ReillyBrogan wrote:

My LVM+LUKS setup booted fine and properly displayed the password prompt during boot.

My LVM+LUKS setup booted fine and properly displayed the password prompt during boot.

@riffer: Interesting. Seems like during the initial inclusion that folder was changed, when it was updated to version 1.7 (between https://dev.getsol.us/D10544?id=26324 and https://dev.getsol.us/D10544?id=26652)
But the instructions upstream clearly state [...]/firmware/intel/

Just a follow up.

I thought I would post this here given that the other issues are closed.

I did as Joshua Strobl suggested. I switched to unstable, updated, and managed to boot successfully with kernel 5.14-16-205 (the one with the patch), and then switched back to stable. Glad to see it worked! Thank you JoshStrobl and zmaint for your help!

Evidently folks opted to push packages after the kernel, so it is going to have to wait. Bunch of stuff needing testing in unstable now.

No problem. Will get it deployed to stable repo shortly.

It's a straight up AMD, I only use it for work so no virtualbox or any other kernel add-ons.

@zmaint I have backported that patch to our 5.14.16. Assuming you are not using any supplemental kernel modules (e.g. bbswitch, broadcom-sta, nvidia proprietary drivers, virtualbox, etc.) you can use the following instructions to install it. If you are using the unstable repo, then you can upgrade as normal to test.

Thank you much appreciated. I'm ok sticking with the older kernel until the next update whenever that comes.

In T10000#189847, @zmaint wrote:

They said to please make sure the kernel has this patch.

commit afd18180c07026f94a80ff024acef5f4159084a4
Author: Yifan Zhang <yifan1.zhang@amd.com>
Date: Mon Oct 11 20:37:01 2021 +0800

drm/amdkfd: fix boot failure when iommu is disabled in Picasso.

When IOMMU disabled in sbios and kfd in iommuv2 path, iommuv2
init will fail. But this failure should not block amdgpu driver init.

Reported-by: youling <youling257@gmail.com>
Tested-by: youling <youling257@gmail.com>
Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
Reviewed-by: James Zhu <James.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

They said to please make sure the kernel has this patch.

Just updated to the new kernel and the issue is the same. Booting from 5.14.14-202.current works fine.

I have updated our kernel to 5.14.16, which features multiple changes for drm/amd/display and drm/amdgpu. If you are unstable, the update is available now. If you are on stable, this will be pushed on Friday. Not marking as resolved, however if it isn't resolved beyond these changes I would encourage you to file an issue at https://gitlab.freedesktop.org/drm/amd/-/issues so it can be triaged and addressed upstream by the folks responsible for the development and support of this hardware in the kernel.

Hey, i would like to request the driver for my DS-640 Mobil Scanner, as i cant get another one for a reasonable price i would have loved if this could work under solus, using a w10vm just for scanning is kinda annoying.

I double checked everything to see if it was plugged correctly and tried it on windows (just to be sure the unit was working properly by itself).