| View previous topic :: View next topic |
| Author |
Message |
kon14
n00b
Joined: 27 Nov 2014
Posts: 34
|
 Posted: Fri Jan 23, 2015 5:04 pm Post subject: |
 |
|
I forgot it's an external module. Just reinstalled it, though copying it would probably suffice.
I can now start the fglrx profile and see that fglrx is present in the output of lsmod, though so does radeon and fglrx isn't used by anything yet :/
Should I kill try killing radeon by force so as for fglrx to take hold?
I think it's getting real close now  |
|
| Back to top |
|
 |
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Fri Jan 23, 2015 5:56 pm Post subject: |
|
|
| kon14 wrote: | | Should I kill try killing radeon by force so as for fglrx to take hold? |
This is where hprofile comes into play... because if you remove radeon... it's bye bye the screen. So, you have hprofile to unload radeon/kms/ttm modules and then load fglrx/uvesafb, and swap 40-monitor.conf into `/etc/X11/xorg.conf.d' for X server.
Well, then test switching profiles.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/ |
|
| Back to top |
|
|
kon14
n00b
Joined: 27 Nov 2014
Posts: 34
|
| Posted: Fri Jan 23, 2015 6:18 pm Post subject: |
|
|
| tclover wrote: | | kon14 wrote: | | Should I kill try killing radeon by force so as for fglrx to take hold? |
This is where hprofile comes into play... because if you remove radeon... it's bye bye the screen. So, you have hprofile to unload radeon/kms/ttm modules and then load fglrx/uvesafb, and swap 40-monitor.conf into `/etc/X11/xorg.conf.d' for X server.
Well, then test switching profiles. |
So I make a small script featuring hprofile -s vga.radeon, hprofile vga.fglrx and moving the 40-monitor.conf to the right dir?
Should I also move the xorg.conf file? Then? |
|
| Back to top |
|
|
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Fri Jan 23, 2015 6:48 pm Post subject: |
|
|
| kon14 wrote: | So I make a small script featuring hprofile -s vga.radeon, hprofile vga.fglrx and moving the 40-monitor.conf to the right dir?
Should I also move the xorg.conf file? Then? |
No. Just fire `hprofile vga.fglrx' if radeon profile is being used, or `hprofile vga.radeon' if fglrx profile isbeing used..
(`/etc/X11/xorg.conf.d/40-monitor.conf' would be symlinked to `/etc/hprofile/profiles/vga/files/etc/X11/xorg.conf.d/40-monitor.conf.$PROFILE' automaticaly! Why are you using hprofile in first place?!)
And then check that fglrx is being used by the kernel, well the GPU device should be using it by now if switching went smoothly (uvesafb should be there, or else... no linux console will be available.)
Checks say OK? Then fire X server for additional testings.
EDIT: `lspci -k' is your friend to see what driver is being used by what device.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/ |
|
| Back to top |
|
|
kon14
n00b
Joined: 27 Nov 2014
Posts: 34
|
| Posted: Fri Jan 23, 2015 7:34 pm Post subject: |
|
|
| tclover wrote: |
No. Just fire `hprofile vga.fglrx' if radeon profile is being used, or `hprofile vga.radeon' if fglrx profile isbeing used..
(`/etc/X11/xorg.conf.d/40-monitor.conf' would be symlinked to `/etc/hprofile/profiles/vga/files/etc/X11/xorg.conf.d/40-monitor.conf.$PROFILE' automaticaly! Why are you using hprofile in first place?!)
And then check that fglrx is being used by the kernel, well the GPU device should be using it by now if switching went smoothly (uvesafb should be there, or else... no linux console will be available.)
Checks say OK? Then fire X server for additional testings.
EDIT: `lspci -k' is your friend to see what driver is being used by what device. |
I kill kdm and login to the shell, login as root, do hprofile vga.radeon, then check with lspci -k.
While fglrx is loaded as a module, the kernel driver being used by my gpu is radeon which cannot be removed (even with modprobe -rf)
40-monitor.conf is indeed a symlink to the appropriate profile's file |
|
| Back to top |
|
|
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Fri Jan 23, 2015 7:44 pm Post subject: |
|
|
| kon14 wrote: | I kill kdm and login to the shell, login as root, do hprofile vga.radeon, then check with lspci -k.
While fglrx is loaded as a module, the kernel driver being used by my gpu is radeon which cannot be removed (even with modprobe -rf) |
Well, then try to uncomment `echo 0 >/sys/class/vtconsole/vtcon1/bind' in `radeon.stop' file and the other lines then... And try again. If it does not work, you will have to search on the intertubes which file to play with to be able unload radeon kernel module.
WARN: You should be doing this with hprofile to avoid having to reboot for nothing; because you have to complete the task of completly removing a kernel module, in order to start another profile.
Luck!
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/ |
|
| Back to top |
|
|
kon14
n00b
Joined: 27 Nov 2014
Posts: 34
|
| Posted: Fri Jan 23, 2015 7:53 pm Post subject: |
|
|
| tclover wrote: |
Well, then try to uncomment `echo 0 >/sys/class/vtconsole/vtcon1/bind' in `radeon.stop' file and the other lines then... And try again. If it does not work, you will have to search on the intertubes which file to play with to be able unload radeon kernel module.
WARN: You should be doing this with hprofile to avoid having to reboot for nothing; because you have to complete the task of completly removing a kernel module, in order to start another profile.
Luck! |
UPDATE:
This shouldn't work since you can't write in /sys/class/vtconsole1/bind :S
Nevermind this, I mistook it for the the/sys/class/drm/card0/power files, but it's uncommented already so there's nothing to alter :/ |
|
| Back to top |
|
|
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Fri Jan 23, 2015 8:26 pm Post subject: |
|
|
| kon14 wrote: | | This shouldn't work since you can't write in /sys/class/vtconsole1/bind :S |
That's weird...
| ls -l /sys/class/vtconsole/vtcon1/: |
-rw-r--r-- 1 root root 4096 Jan 22 23:13 bind
-r--r--r-- 1 root root 4096 Jan 22 23:13 name
drwxr-xr-x 2 root root 0 Jan 23 21:20 power
lrwxrwxrwx 1 root root 0 Jan 22 02:20 subsystem -> ../../../../class/vtconsole
-rw-r--r-- 1 root root 4096 Jan 22 23:13 uevent
|
... means writable by root.
Unfortunately, I cannot test it because I have a hardware with latest nVidia Maxwell GPU... unusable at the moment with nouveau (BOSD(TM).)
Lets see... that workaround comes from http://nouveau.freedesktop.org/wiki/ that page. A bit old, but still a workaround.
Well, lets see where I did found it in the past on nouveau wiki.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/ |
|
| Back to top |
|
|
kon14
n00b
Joined: 27 Nov 2014
Posts: 34
|
| Posted: Fri Jan 23, 2015 8:34 pm Post subject: |
|
|
| tclover wrote: |
That's weird...
| ls -l /sys/class/vtconsole/vtcon1/: |
-rw-r--r-- 1 root root 4096 Jan 22 23:13 bind
-r--r--r-- 1 root root 4096 Jan 22 23:13 name
drwxr-xr-x 2 root root 0 Jan 23 21:20 power
lrwxrwxrwx 1 root root 0 Jan 22 02:20 subsystem -> ../../../../class/vtconsole
-rw-r--r-- 1 root root 4096 Jan 22 23:13 uevent
|
... means writable by root.
|
Again my fault for messing up the names, this one is indeed writable, but I didn't have it commented out so there's nothing to change.
I believe there's no problems with loading fglrx, let me run a new xorg and paste the log.
The problem must be radeon not letting hold of its in_use seat |
|
| Back to top |
|
|
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Fri Jan 23, 2015 8:48 pm Post subject: |
|
|
| kon14 wrote: | I believe there's no problems with loading fglrx, let me run a new xorg and paste the log.
The problem must be radeon not letting hold of its in_use seat |
That's just part of the issue here... fglrx should take over the device--that's why writing to that file might be required, to force radeon release the frame buffer device,--and then load uvesafb in order to get... a frame buffer device.
So, checkout which driver is being used by the device.
| lspci -k: | (....)
Kernel driver in use: fglrx
(...) |
Should be apparent on the device. No need to post unnecessary info!
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/ |
|
| Back to top |
|
|
kon14
n00b
Joined: 27 Nov 2014
Posts: 34
|
| Posted: Fri Jan 23, 2015 8:51 pm Post subject: |
|
|
This is my xorg log after selecting the fglrx profile and starting the x server:
http://pastebin.com/cRrLpQLt
And this is the output of lspci -k after doing so:
http://pastebin.com/ThK3J12r
As you can see in 02:00.0 radeon remains the module in use and that's probably why X gives me the blacks again,
PS: Just noticed the above reply, I had already mentioned that radeon is used instead so I included everything, no matter there's probably nothing else worth noting there. |
|
| Back to top |
|
|
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Fri Jan 23, 2015 9:03 pm Post subject: |
|
|
I see, the problem is to make radeon release the device... Is uvesafb successfully loaded as well?
If it's the case... you should try find some info on how to unload radeon... if there is a file to write to in order to do that. If not, you will have to reboot in order to change profile: you can simply black list everything (radeon & fglrx), maybe let uvesafb loaded in order to get linux console, and then change the default profile.
| cat /etc/hprofile/profiles/vga/default: | | fglrx |
(Or radeon of course.)
(Well, you might remove ptest file in this case, because it will be a source of trouble.)
Or else, use only black listing a module to be able to get the other loaded, but ensure fglrx+uvesafb in the other case in order to get linux console.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/ |
|
| Back to top |
|
|
kon14
n00b
Joined: 27 Nov 2014
Posts: 34
|
| Posted: Fri Jan 23, 2015 9:12 pm Post subject: |
|
|
| tclover wrote: | I see, the problem is to make radeon release the device... Is uvesafb successfully loaded as well?
If it's the case... you should try find some info on how to unload radeon... if there is a file to write to in order to do that. If not, you will have to reboot in order to change profile: you can simply black list everything (radeon & fglrx), maybe let uvesafb loaded in order to get linux console, and then change the default profile.
| cat /etc/hprofile/profiles/vga/default: | | fglrx |
(Or radeon of course.)
(Well, you might remove ptest file in this case, because it will be a source of trouble.)
Or else, use only black listing a module to be able to get the other loaded, but ensure fglrx+uvesafb in the other case in order to get linux console. |
I think I'll try blacklisting except uvesafb, then reboot and select fglrx, then startx.
If it starts then the issue is radeon not releasing the device. If not, then thtere's more into it.
I'll also try finding out more about radeon, perhaps a graphics related irc would be helpful.
There's currently no default profile. If I should create one by echoing radeon/fglrx into it will it run on boot/stay the default?
Concerning uvesafb it loads, but I didn't search for it in lsmod last time I restarted xorg with fglrx profile so I don't know whether it's used by anything.
I'll make sure to check it again on next try. |
|
| Back to top |
|
|
kon14
n00b
Joined: 27 Nov 2014
Posts: 34
|
| Posted: Fri Jan 23, 2015 10:20 pm Post subject: |
|
|
Making some small steps towards success!
I'm actually capable of booting a perfect fglrx session the way I mentioned above, so I guess I only need to find out how to do so.
I'll probably call it a day for now. I'll reply about on my progress as soon as I make any.
tclover, thanks for all this help, it's truly appreciated.
Even though I won't mark it the topic as [Solved] yet, I already got the nice feeling you get after fixing something in gentoo and learning more about your system.
Gets me every time 
Hopefully I'll post the solution here soon and you can include it in the documentation/man page/comments of fglrx/radeon.start/stop (?) |
|
| Back to top |
|
|
|
Desktop Environments
