search

puppylinux-woof-CE / woof-CE

woof - the Puppy builder
GNU General Public License v2.0
396 stars 282 forks source link

Problems installing nvidia with new xorgwizard #847

Closed peabee closed 7 years ago

peabee commented 8 years ago

Had a big struggle today installing the nvidia 304.131-patched-k4.6 driver into a system with kernel 4.6.4-pae and BUILD_FROM_WOOF='testing;53ed20e;2016-08-06 21:30:22 +0000'

1st try was to install the .sfs and then reboot as normal - this failed totally with no desktop reached and error messages during boot

2nd try was to blacklist nouveau and reboot creating savefolder then install .sfs then reboot again - desktop was reached but both mouse and keyboard were kaput=dead

3rd try - which was eventually successful - was to manually copy /etc/X11/xorg.conf from an earlier working system into the savefolder of try #2 and reboot

In various states xorgwizard was run from the console but at no time was the nvidia driver offered as an option to choose - just 3 options - to continue, choose screen resolution or try xvesa....

peabee commented 8 years ago

the nvidia .sfs was built with getnvidia - does this need to be amended for the new xorgwizard process??

wdlkmpx commented 8 years ago

Well, this new xorgwizard does not detect the video driver.. ddcprobe used to get that info. xorg can detect the correct video driver automatically, you just don't have to mess with the xorg.conf file.

I think Billtoo reported this before, yes the getnvidia stuff needs some fixing for woofce. Although you can run xorgwizard-automatic at the end and it will fix any issues because it will reset the xorg.conf file.

There is a proper xorg.conf template, at least for the video stuff, however the input stuff is something that needs some work, as reported by a user in the xenialpup thread.

wdlkmpx commented 8 years ago

I redesigned xorgwizard-cli, https://github.com/puppylinux-woof-CE/woof-CE/commit/885be6162b9c68a6d167435d75231c090fe3d0f6

Screenshots: http://murga-linux.com/puppy/viewtopic.php?p=927343#927343

this might work as expected. so build from rationalise one of these days and please remove /usr/sbin/xorgwizard from the ydrv... it's oudated and xorgwizard-cli and xorgwizard-automatic are symlinks to it.

Nothing changes by adding the alternative xorg, unless you add a special flag file or edit DISTRO_SPECS. See: http://murga-linux.com/puppy/viewtopic.php?p=927237#927237

peabee commented 8 years ago

I'm not sure I really understand this mechanism.....

Or you can add this file: "/var/local/xwin_no_xorg_auto_flag" in a adrv or something.

unless you add a special flag file or edit DISTRO_SPECS.

Are users meant to do this?? Why can't xorgwizard create this file for a user if it is needed?? I'll make the change requested to ydrv.....

peabee commented 8 years ago

Should file: "/var/local/xwin_no_xorg_auto_flag" be in the ydrv????

peabee commented 8 years ago

Somewhere between rationalise-2209 and rationalise 0310 the middle scroll wheel on my mouse has stopped working.....

01micko commented 8 years ago

I can confirm the scrollwheel bug. Affects touchscreen too. The bug is in the latest slacko beta versions.

On Sat, Oct 8, 2016 at 7:24 PM, PB notifications@github.com wrote:

Somewhere between rationalise-2209 and rationalise 0310 the middle scroll wheel on my mouse has stopped working.....

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/puppylinux-woof-CE/woof-CE/issues/847#issuecomment-252414062, or mute the thread https://github.com/notifications/unsubscribe-auth/AA-M71uIrkMOzsdkBnnjdSI98bWXXDwWks5qx2E6gaJpZM4JkWUW .

peabee commented 8 years ago

so build from rationalise one of these days and please remove /usr/sbin/xorgwizard from the ydrv...

delta built with rationalise;a42adda;2016-10-08 09:19:21 +1000 here

on my desktop with nvidia graphics selecting xvesa results in no desktop - installing ydrv and selecting fallback xorg also results in no desktop.....

peabee commented 8 years ago

Test with nvidia proprietary sfs much more successful - correctly changed over from nouveau to nvidia after the reboot with mouse working apart from scroll-wheel problem screenshot

wdlkmpx commented 8 years ago

The "flag" file is meant to be used as a retro approach for the first boot maybe... remember the retro puppies used to come with xorgwizard-cli activated by default while the normal puppies will try to boot to desktop?... yes that is the same idea. i'll look into the mouse issue.

If you think that flag the flag file should not be there, then it shouldn't. i have no problems.. it's easy to activate the the xorgwizard-cli mechanism...

wdlkmpx commented 8 years ago

so peebee do you have any suggestions for the new xorgwizard-cli design or is it good enough?

peabee commented 8 years ago

Scroll-wheel problem now solved

so peebee do you have any suggestions for the new xorgwizard-cli design or is it good enough?

The cli seems fine - but switching to the vesa driver does not work for me....

01micko commented 8 years ago

vesa driver doesn't work with KMS. You need to boot with nomodeset. YMMV

If KMS is loaded you should try 'modesetting' driver. Works for me on radeon. Haven't tried with nvidia.

peabee commented 8 years ago

vesa driver doesn't work with KMS. You need to boot with nomodeset. YMMV If KMS is loaded you should try 'modesetting' driver. Works for me on radeon. Haven't tried with nvidia.

Thanks - I've learnt something.... As vesa is always offered as an option, is it possible to detect that this is an invalid option when it is selected and then offer advice as to what to do instead?

modesetting apparently works, but all indications seem to show that nouveau is really still in charge....the only way to really get rid of nouveau is to blacklist it and reboot. A desktop then appears that is probably vesa although some system tools report it as vesa and some still report it as nouveau although lsmod shows that nouveau is not loaded.

Getting rid of nouveau is an important aspect of making the nvidia proprietary driver with get-nvidia as the build process will not complete whilst nouveau is being used.....

01micko commented 8 years ago

An important distinction is between the nouveau kernel module and the nouveau X.org driver.

If KMS is on then yes, nouveau kernel module will load, but if a user chooses "modesetting" driver then the X.org nouveau driver is not loaded.

Of course KMS must be off if using the proprietery nvidia (same with fglrx) which is achieved in a number of ways (whch are well publicised so I wont go through that here).

So, what tests can be done to see if KMS is loaded (and hence nouveau kernel module, radeon kernel module etc)?

A shortlist is to grep for 'kms' of the 'lsmod' command. Test the kernel commandline. test for files in /etc/modprobe.d. probably more by searching /proc.

On Mon, Oct 10, 2016 at 9:34 PM, PB notifications@github.com wrote:

vesa driver doesn't work with KMS. You need to boot with nomodeset. YMMV If KMS is loaded you should try 'modesetting' driver. Works for me on radeon. Haven't tried with nvidia.

Thanks - I've learnt something.... As vesa is always offered as an option, is it possible to detect that this is an invalid option when it is selected and then offer advice as to what to do instead?

modesetting apparently works, but all indications seem to show that nouveau is really still in charge....the only way to really get rid of nouveau is to blacklist it and reboot. A desktop then appears that is probably vesa although some system tools report it as vesa and some still report it as nouveau although lsmod shows that nouveau is not loaded.

Getting rid of nouveau is an important aspect of making the nvidia proprietary driver with get-nvidia as the build process will not complete whilst nouveau is being used.....

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/puppylinux-woof-CE/woof-CE/issues/847#issuecomment-252594070, or mute the thread https://github.com/notifications/unsubscribe-auth/AA-M7_HsqjzcjOjn3fpZdrAkGZNOP5pKks5qyiKsgaJpZM4JkWUW .

wdlkmpx commented 8 years ago

Today i compiled the nvidia propietary driver. It was a nightmare, after identifying the correct driver version, getnvidia failed. The reason was not obvious.

So i got bored and created a small db with all the legacy versions, supported device ids/ xorg versions/kernel versions. Only the max supported kernel is unknown, but it's clear all the legacy drivers are broken for newer kernels and xorg versions. The key xorg versions are 1.5-8? (or so), 1.12, 1.15.

Well i installed the nvidia driver manually (kernel 3.14), but first i applied 4 patches i found. The leads were in a slackware doc and the murga-forum (CatDude) http://www.flaterco.com/kb/video/X-regressions.html#nvvers http://www.murga-linux.com/puppy/viewtopic.php?t=95382

After installing the driver (which was quite straightforward), now i understand the role of VertRefresh

# VertRefresh  59-75

All the other drivers work fine without it, but the (legacy) nvidia driver only showed 640x480. After i specified a conservative value, the gui showed all the available resolutions up to 1920x1080

VertRefresh  59-60

What do i do think about this? well, i'm not sure, but being retro comes with a high price.

peabee commented 7 years ago

Latest install of nvidia-304.135 under kernel 4.10.5 went much smoother so I think this issue can be closed.