| View previous topic :: View next topic |
| Author |
Message |
kon14
n00b
Joined: 27 Nov 2014
Posts: 34
|
 Posted: Sun Jan 18, 2015 11:23 am Post subject: fglrx/mesa switchable setup fails, need help |
 |
|
Hi guys, I need help setting up fglrx/mesa graphis in my gentoo installation.
I've already searched through the forums and though some topics have given me food for though, I don't seem to have fixed my issues as of yet.
I'm trying to install catalyst along my radeonsi installation so as to be able to switch between them and do some game testing.
As of now, I have added fglrx to my make.conf (after radeon and radeonsi), updated my world, checked for rebuilds.
I have generated a xorg.conf file and run aticonfig --initial --input=thefile on it.
I try to switch to catalyst by eselecting opengl ati, moving a blacklist file to /etc/modprobe.d/ or creating one, containing either a blacklist for radeon and fbcon or for fglrx, then restarting my desktop.
With the above setup I've only managed to get to a black screen after init or get a black screen with a frozen underscore in the top-left corner.
I can only revert back to mesa reversing the above actions and moving the xorg.conf file out of the way.
Any help at all would be appreciated  . |
|
| Back to top |
|
 |
sebB
l33t
Joined: 02 Mar 2011
Posts: 806
Location: S.O. France
|
| Posted: Tue Jan 20, 2015 9:24 pm Post subject: |
|
|
I think the solution is to create 2 entries in your grub (1 for radeon, 1 for fglrx) and adding the blacklist options in the kernel + nomodeset
After simply a script to start on radeon or fglrx.
If you blacklist fglrx, rebuild your intramfs, switch opengl, does the radeon(si) work?
If you add nomodeset to your kernel, blacklist radeon..., rebuild your intramfs, run aticonfig..., switch opengl to ati does fglrx work?
Can you post lsmod, eselect mesa list and eselect opengl list without any blacklist. |
|
| Back to top |
|
|
kon14
n00b
Joined: 27 Nov 2014
Posts: 34
|
| Posted: Wed Jan 21, 2015 3:22 pm Post subject: |
|
|
By adding the blacklist options in the kernel you mean as a parameter or as a secondary kernel with the appropriate options built-in?
I am able to revert to radeonsi after eselecting opengl xorg, removing the blacklists and moving the xorg.conf file out of /etc/.
I don't use an initramfs, how do I blacklist a module in grub2 (radeon support is built as a module, not built-in)?
I'll try with nomodeset first. |
|
| Back to top |
|
|
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Wed Jan 21, 2015 11:52 pm Post subject: |
|
|
Yes, you may have to black list a kernel module in order to get a _default_ kernel module upon system boot. But, you won't normally need to go as far as rebooting to switch between the two profiles. However, you should build almost all drm/kms drivers as kernel module or else... you'll be getting those BOSD(TM) (Black (instead of _Blue_) Screen Of Death.)
And you will have to script the change in order to be _able_ to switch between both profile because... once the screen is off because a fb driver is unloaded, you won't be able to finish the task.
This is where hprofile enter into play here. Emerge _hprofile_ package (or follow the overlay on my sig for the latest version) and _do_ take care of uncommenting drm/kms module unloading in `radeon.stop' script (which are commented out by default.) Then, check `40-monitor.conf.{radeon,fglrx}' configuration files; And then go to test it.
Do not hesitate to post feed back because... the scripts may be a little out dated.
Good luck!
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/ |
|
| Back to top |
|
|
kon14
n00b
Joined: 27 Nov 2014
Posts: 34
|
| Posted: Thu Jan 22, 2015 1:47 pm Post subject: |
|
|
I'm currently building a new kernel. I modularised Direct Rendering Manager and kept ATI Radeon as module. Could the kernel drm be what caused the bsod?
Should I include in-kernel firmware blobs in kernel binary or will this interfere with fglrx? Will I still need nomodeset in kernel parameters?
I'm already using a script to complete the process, but I initially thought I needed to eselect opengl, blacklist whatever's needed, put an appropriate xorg.conf in /etc/X11/ and reboot so as for my system to apply the changes in a sane way.
What else should be included in the script (actually how do I include hprofile in the mixture? do I only need the radeon.stop script or should the above be a subset of another hprofile script)? At which point does X driver take control over Y driver? Do I use this radeon.stop script to kill radeon?
I've never worked with hprofile so please bear with me. What is it that needs to be uncommented/commented exactly? My radeon.stop has this comment in it: "Comment the following line and uncomment the other lines
# to force remove nouveau/kms driver for e.g. fglrx", but the only loaded module (of the 3 below) seems to be drm_kms_helper. Here's the actual script for the sake of convenience: http://pastebin.com/F2r4CCAH
Do I really need to uncomment them all?
Thanks for all of the above |
|
| Back to top |
|
|
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Thu Jan 22, 2015 2:25 pm Post subject: |
|
|
| kon14 wrote: | I'm currently building a new kernel. I modularised Direct Rendering Manager and kept ATI Radeon as module. Could the kernel drm be what caused the bsod?
Should I include in-kernel firmware blobs in kernel binary or will this interfere with fglrx? Will I still need nomodeset in kernel parameters? |
(Sorry to have thrown all those info at once.)
Possibly... I don't remember quite well now... but you need an extra fb driver to pair with fglrx, I guess it's uvesafb (so, build this as module and black list it right away.)
So, if you're going to the module+script (ie sys-apps/hprofile), you won't need the nomodeset cmdline anymore.
By the way, is EFI involved with this? If it's the case, build EFIfb into the kernel; Or else, pick up another one (not uvesafb because it's incompatible with drm/kms driver.)
(I don't remember other usefull name but... uvesafb. WARN: And _do_ not build old fb driver into the kernel either! for drm/kms incompatibility.)
| kon14 wrote: | I'm already using a script to complete the process, but I initially thought I needed to eselect opengl, blacklist whatever's needed, put an appropriate xorg.conf in /etc/X11/ and reboot so as for my system to apply the changes in a sane way.
What else should be included in the script (actually how do I include hprofile in the mixture? do I only need the radeon.stop script or should the above be a subset of another hprofile script)? At which point does X driver take control over Y driver? Do I use this radeon.stop script to kill radeon? |
First are you going the easy way (sys-apps/hprofile) or a custom way (which might be easy as well)?
If you decide to pick up sys-apps/hprofile, almost everything is set up for this end, namely switch between driver. You just have to check out the configuration files as said previously; And then uncomment drm/kms module unloading from `radeon.stop' script in order to load fglrx (and possibly uvesafb to have Linux console.) Switching between OpenGL is already managed by hprofile by default. Although, you have to add loading uvesafb in `fglrx.start' and unloading in `fglrx.stop'. This is not done by default... still, again, I don't remember precisely anymore which fb driver to pair with fglrx in order to get Linux console. uvesafb is used for this end with nVidia(blob).
So, black list what extra fb driver you choose to go with fglrx (uvesafb? and if uvesafb is involved, merge sys-apps/v86d as well) if you intend to have radeon/drm/kms upon system boot; Or vice versa for the opposite. And I recommand going to sys-apps/hprofile for a possibly easy way... because there are quite a few things to take care of: module [un]loading, OpenGL profile switch; X configuration file swap. And hprofile was written for this purpose to ease this kind of hardware/software scenarios.
Good luck!
| kon14 wrote: | | I've never worked with hprofile so please bear with me. What is it that needs to be uncommented/commented exactly? My radeon.stop has this comment in it: "Comment the following line and uncomment the other lines(...) |
Almost forget about this, run `emerge -av sys-apps/hprfile' and you will have the files I am talking about installed in the system. And then, as you may notice at first glance, radeon/drm/kms kernel module unloading are commented out; And you _do_ need those lines to be executed, right?... so go ahead.
(Again...)Luck!
EDIT: There is an error on `radeon.stop'... it shoudl be `rmmod radeon' instead 'rmmod nouveau'. So, correct this easy error.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/ |
|
| Back to top |
|
|
kon14
n00b
Joined: 27 Nov 2014
Posts: 34
|
| Posted: Thu Jan 22, 2015 6:05 pm Post subject: |
|
|
It's a pleasure to gather so much information 
The uvesafb would require an initramfs, right? I suppose I should build uvesafb (Userspace VESA VGA graphics support, kernel option) as module and set "Enable Kernel EDID" and the "Connector - unified userspace - kernelspace linker" as built-ins?
Then blacklist it so as to launch with mesa graphics.
I'm not using efi in my system. The "old" fb driver translates to the ATI Radeon display support inside the Frame Buffer Devices section or the whole frame buffer section?
EDIT: Damn, I didn't notice this whole userspace VESA option. Wait, uvesafb requires this one :S What is it that needs/can be disabled?
At the time of the above post I had already installed hprofile (from gentoo repositories) and fixed the nouveau copying typo.
I removed the comments and will try the new built after I decide on the framebuffer issue (see below).
I believe I remember though that catalyst never worked out pretty well with framebuffers at all :S.
There's also this part of the wiki: http://wiki.gentoo.org/wiki/Fglrx
where the main framebuffer option is disabled in the kernel config.
But I guess I'll need something to work with the console other than sshing after all.
I'm sorry for all these questions,
Constantine
EDIT2: The new setup gives me a kernel panic (not syncing VFS: unable to mount root fs on unknown-block(0,0) so my kernel doesn't really boot the system atm). I have built uvesafb according to the wiki, though I've only specified the v86d initramfs in the kernel (/usr/share/v86d/initramfs), meaning there's no initramfs in grub's configuration. |
|
| Back to top |
|
|
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Thu Jan 22, 2015 7:23 pm Post subject: |
|
|
You get what have to be done quite well: build radeon/drm/kms as module in order to able to unload them and kick in fglrx driver.
Then you have to decide the default driver by black listing radeon or fglrx depending on your needs. (I'm merely restating here what I've previously said.)
Now, the remaining issue is to have a fb driver for linux console. I did not quite follow the details about fglrx+fb driver... so you will have to experiment and try to gather some info for this. So, before going to uvesafb route, try to find some info to avoid wasting unnecessary time. Once, the additional fb driver is determined, just build it into the kernel if it does not conflict with radeon/drm/kms. This is because, once radeon driver is loaded, it will take over the device.
So, will remain a little tweak to `radeon.st{art,op}' to get going with possibly that extra fb driver.
If there is no workaround for this additional fb driver... I guess you'd have to issue `hprofile vga.radeon' in a X session... with the expected issues wich will get in.
Good luck!
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/ |
|
| Back to top |
|
|
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Thu Jan 22, 2015 7:26 pm Post subject: |
|
|
| kon14 wrote: | | EDIT2: The new setup gives me a kernel panic (not syncing VFS: unable to mount root fs on unknown-block(0,0) so my kernel doesn't really boot the system atm). I have built uvesafb according to the wiki, though I've only specified the v86d initramfs in the kernel (/usr/share/v86d/initramfs), meaning there's no initramfs in grub's configuration. |
You normally won't need that initramfs if you don't have any fbsplash related theme going... The screen resolution will be a little gross but that's all. Avoid that initramfs just to be able to switch driver!
To re-adjust the screen resolution once booted, just run `/etc/init.d/consolefont restart' if hprofile is not added to either boot or default run level. No clue, for systemD related thing, so don't ask!
EDIT: v86d would be necessary if you choose to go to uvesafb route, and it will only serve to reajust the screen resolution defined on the kernel cmdline with `video=<something>' only! So no initramfs for nothing, especially if you don't have `video=...' cmdline.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/ |
|
| Back to top |
|
|
kon14
n00b
Joined: 27 Nov 2014
Posts: 34
|
| Posted: Thu Jan 22, 2015 9:32 pm Post subject: |
|
|
| tclover wrote: | | Now, the remaining issue is to have a fb driver for linux console. I did not quite follow the details about fglrx+fb driver... so you will have to experiment and try to gather some info for this. So, before going to uvesafb route, try to find some info to avoid wasting unnecessary time. Once, the additional fb driver is determined, just build it into the kernel if it does not conflict with radeon/drm/kms. This is because, once radeon driver is loaded, it will take over the device. |
I actually searched through some related threads and found out uvesafb should work better with fglrx than most other fbs.
I forgot to blacklist it uvesafb though (since there won't be vesa, shouldn't it be running for the shells to be accessible without kms etc?)
Actually my fault, I shouldn't blacklist, just not launch with mesa?
So, will remain a little tweak to `radeon.st{art,op}' to get going with possibly that extra fb driver.[/quote]
That's removing uvesafb in fglrx.stop and modprobing it in fglrx.start, right?
| tclover wrote: | | If there is no workaround for this additional fb driver... I guess you'd have to issue `hprofile vga.radeon' in a X session... with the expected issues wich will get in. |
I'll try rebuilding without initramfs and not loading uvesafb at boot (?) since I'll start with radeon first and see how that goes.
| tclover wrote: | | To re-adjust the screen resolution once booted, just run `/etc/init.d/consolefont restart' if hprofile is not added to either boot or default run level. No clue, for systemD related thing, so don't ask! |
That's initrc actually, though hopefully there won't be a reason to ask.
| tclover wrote: | | v86d would be necessary if you choose to go to uvesafb route, and it will only serve to reajust the screen resolution defined on the kernel cmdline with `video=<something>' only! So no initramfs for nothing, especially if you don't have `video=...' cmdline. |
I'll remove that from grub then, will uvesafb still work after unmerging v86d? The wiki doesn't really talk much about them |
|
| Back to top |
|
|
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Thu Jan 22, 2015 9:54 pm Post subject: |
|
|
| kon14 wrote: | I actually searched through some related threads and found out uvesafb should work better with fglrx than most other fbs.
I forgot to blacklist it uvesafb though (since there won't be vesa, shouldn't it be running for the shells to be accessible without kms etc?) |
Good to hear that, I will add uvesafb in feature release of hprofile then. (I will push a few commits for this later; if you want to test... follow the overlay on my sig.)
This is not a problem if radeon is loaded and take over the screen. Just black list uvesafb & fglrx then.
| kon14 wrote: | | That's removing uvesafb in fglrx.stop/radeon.start etc, right? |
That's exactly the opposite... don't you need a fb driver in order to get linux console? Yes, you do; So, add `modprobe uvesafb' to `fglrx.start' and `rmmod uvesafb' in `fglrx.stop'. I am not sure if you need to remove uvesafb if loading radeon driver take over the screen, so be it, you can just leave it then. The same goes for loading uvesafb... Is it necessary to black list uvesafb at all? Or loading radeon module is enough? I am asking this because this is critical for nouveau: uvesafb _should_ not be there (so removing it is necessary.)
| kon14 wrote: | | I'll try rebuilding without initramfs and blacklisting uvesafb since I'll start with radeon first and see how that goes. |
Fine, go and test then!
| kon14 wrote: | | I'll remove that from grub then, will uvesafb still work after unmerging v86d? The wiki doesn't really talk much about them |
You do not need to remove `video=...' cmdline if you have any. Just leave it there and keep minimal settings (resolution would be enough) because uvesafb support exotic options that radeon module do not.
Luck!
(Pushing some commits with uvesafb then.)
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/ |
|
| Back to top |
|
|
kon14
n00b
Joined: 27 Nov 2014
Posts: 34
|
| Posted: Thu Jan 22, 2015 10:17 pm Post subject: |
|
|
| tclover wrote: | | kon14 wrote: | I actually searched through some related threads and found out uvesafb should work better with fglrx than most other fbs.
I forgot to blacklist it uvesafb though (since there won't be vesa, shouldn't it be running for the shells to be accessible without kms etc?) |
Good to hear that, I will add uvesafb in feature release of hprofile then. (I will push a few commits for this later; if you want to test... follow the overlay on my sig.)
This is not a problem if radeon is loaded and take over the screen. Just black list uvesafb & fglrx then. |
Then I'll probably give that overlay a shot once I find out how these things should work.
| tclover wrote: | ] | kon14 wrote: | | That's removing uvesafb in fglrx.stop/radeon.start etc, right? |
That's exactly the opposite... don't you need a fb driver in order to get linux console? Yes, you do; So, add `modprobe uvesafb' to `fglrx.start' and `rmmod uvesafb' in `fglrx.stop'. I am not sure if you need to remove uvesafb if loading radeon driver take over the screen, so be it, you can just leave it then. The same goes for loading uvesafb... Is it necessary to black list uvesafb at all? Or loading radeon module is enough? I am asking this because this is critical for nouveau: uvesafb _should_ not be there (so removing it is necessary.) |
That's actually what I was talking about. Loading it for fglrx and removing it later (should this be needed anyway).
| tclover wrote: | | kon14 wrote: | | I'll remove that from grub then, will uvesafb still work after unmerging v86d? The wiki doesn't really talk much about them |
You do not need to remove `video=...' cmdline if you have any. Just leave it there and keep minimal settings (resolution would be enough) because uvesafb support exotic options that radeon module do not.
Luck!
(Pushing some commits with uvesafb then.) |
[/quote]
I hadn't set my resolution before anyway I'll fix that later. I'm rebooting |
|
| Back to top |
|
|
kon14
n00b
Joined: 27 Nov 2014
Posts: 34
|
| Posted: Thu Jan 22, 2015 10:32 pm Post subject: |
|
|
I booted the new kernel successfully (fglrx and uvesafb blacklisted) and can modprobe uvesafb (shows in lsmod but is it really functioning? I can get console without it anyway, so how do I test it?
Concerning the actual switching, do I just run the scripts by hand or should I use hprofile <type>.<profile>?
EDIT: Trying hprofile vga.fglrx, but I get:
Starting vga.fglrx profile
Stoping vga.fglrx profile
rmmod: ERROR: Module fglrx is not currently loaded
* hprofile: failed to remove fglrx module
* hprofile: Failed to run vga/scripts/fglrx.stop script
modprobe: FATAL: Module fglrx not found.
* hprofile: Failed to insert fglrx kernel module
Switching to ati OpenGL interface... done
!!! Error: Can't load module xvmc
exiting
!!! Error: Can't load module xvmc
exiting
Why would it insta-stop the profile? Do I have to explicitly load fglrx or is that somewhere else I missed? |
|
| Back to top |
|
|
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Thu Jan 22, 2015 11:31 pm Post subject: |
|
|
| kon14 wrote: | | I booted the new kernel successfully (fglrx and uvesafb blacklisted) and can modprobe uvesafb (shows in lsmod but is it really functioning? I can get console without it anyway, so how do I test it? |
radeon is taking care of it already... you can probe which fb is being used to print to the display. (... more info for later.)
And this means that uvesafb+radeon is a non issue... so no need to unload uvesafb when switching profile? Not sure about it. You may unload it to be sure to have linux console!
| kon14 wrote: | | Concerning the actual switching, do I just run the scripts by hand or should I use hprofile <type>.<profile>? |
You should!
| kon14 wrote: | EDIT: Trying hprofile vga.fglrx, but I get:
Starting vga.fglrx profile
Stoping vga.fglrx profile
rmmod: ERROR: Module fglrx is not currently loaded
* hprofile: failed to remove fglrx module
* hprofile: Failed to run vga/scripts/fglrx.stop script
modprobe: FATAL: Module fglrx not found.
* hprofile: Failed to insert fglrx kernel module
Switching to ati OpenGL interface... done
!!! Error: Can't load module xvmc
exiting
!!! Error: Can't load module xvmc
exiting
Why would it insta-stop the profile? Do I have to explicitly load fglrx or is that somewhere else I missed? |
It seems the actual version in the official tree is a little out dated... it has that start/stop issue! You should follow the link on my sig. then.
Congrats! You're almost all set! after so much trouble(?). You're all set now. Grab a newer version and test. (NOTE: 4.x is a zsh script, so grab 3.x if you don't have zsh installed.)
_________________
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:13 am Post subject: |
|
|
Today seems to be another day, I'm back to black screens, but the old kernel is affected as well so either hprofile didn't quit properly or I messed up something else.
I'll check my history, get to boot my latest kernel and check the overlay.
Now that I come to think of it I could have tried killing radeon and checking whether I had console with uvesafb so as to see whether it worked.
Blacklisting radeon and booting with fglrx would also check for catalyst + uvesafb.
PS: Out of curiosity I tried starting the radeon profile from recovery. It also instastops and complains about xvmc. |
|
| Back to top |
|
|
kon14
n00b
Joined: 27 Nov 2014
Posts: 34
|
| Posted: Fri Jan 23, 2015 9:19 am Post subject: |
|
|
Seems like I was right about hprofile messing up. Seems like my trying the radeon profile put everything back together.
I'll try the overlay then. |
|
| Back to top |
|
|
kon14
n00b
Joined: 27 Nov 2014
Posts: 34
|
| Posted: Fri Jan 23, 2015 10:28 am Post subject: |
|
|
I installed version 3.2.1 from the overlay. Uncommented the lines in radeon.stop and tried again.
I was actually trying to start vga.fglrx/vga.radeon, though the profile names are vga.at/vga.xorg-x11, as with mere eselect opengl.
I can run hprofile vga.ati/xorg-x11 without it complaining, but lsmod shows that radeon is running anyway and so does uvesafb after switching back to radeon :S
Catalyst is still off.
EDIT: While those 2 (xorg-x11/ati) profiles run, they actually only output:
| Code: |
Starting vga.xorg-x11 profile
consolefont | * Setting console font [default8x16] ...
|
Shouldn't I get vga.radeon/fglrx to work instead like I tried before?
Starting any of radeon or fglrx results in:
| Code: |
Starting vga.radeon profile
/etc/hprofile/profiles/vga/scripts/radeon.start: line 12: echo: write error: Invalid argument
!!! Error: Can't load module xvmc
exiting
!!! Error: Can't load module xvmc
exiting
/etc/hprofile/profiles/vga/scripts/radeon.start: line 15: echo: write error: Invalid argument
/etc/hprofile/profiles/vga/scripts/radeon.start: line 16: echo: write error: Invalid argument
* hprofile: Failed to run vga/scripts/radeon.start script
consolefont | * Setting console font [default8x16] ...
|
(where line15 and 16 are the power profile settings. why is changing the power profile needed at all?)
and
| Code: |
Starting vga.fglrx profile
modprobe: FATAL: Module fglrx not found.
* hprofile: Failed to insert fglrx kernel module
Switching to ati OpenGL interface... done
!!! Error: Can't load module xvmc
exiting
!!! Error: Can't load module xvmc
exiting
* hprofile: Failed to run vga/scripts/fglrx.start script
consolefont | * Setting console font [default8x16] ...
|
(so it can't find the fglrx module?)
Output of find /lib/modules -name "fglrx*":
/lib/modules/3.18.3-gentoo-20150115/video/fglrx.ko
/lib/modules/3.18.2-gentoo-20150115/video/fglrx.ko
Btw, shouldn't: (in radeon.stop)
| Code: |
if ! rmmod radeon; then
echo "failed to remove fglrx module"
|
echo "failed to remove radeon module", instead?
PS: What's the vim line in the end of the file? |
|
| Back to top |
|
|
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Fri Jan 23, 2015 11:57 am Post subject: |
|
|
| kon14 wrote: | I installed version 3.2.1 from the overlay. Uncommented the lines in radeon.stop and tried again.
I was actually trying to start vga.fglrx/vga.radeon, though the profile names are vga.at/vga.xorg-x11, as with mere eselect opengl.
I can run hprofile vga.ati/xorg-x11 without it complaining, but lsmod shows that radeon is running anyway and so does uvesafb after switching back to radeon :S
Catalyst is still off. |
I am completly lost here... what are you talking about?
| # ls /etc/hprofile/profiles/vga/scripts: |
fglrx.start fglrx.stop intel.start nouveau.start nouveau.stop nvidia.start nvidia.stop radeon.start radeon.stop
|
If there is no XvMc implementation installed on the system... Just comment out the appropriate lines to get going of course!
There is no "vga.at/vga.xorg-x11" only `vga.radeon|fglrx'! and you should not mistake one for the other... because it won't do what you expect it to do.
Of course, if those particular profiles do not fit you needs... feel free to edit them.
| kon14 wrote: | Shouldn't I get vga.radeon/fglrx to work instead like I tried before?
(...)
| Code: |
/etc/hprofile/profiles/vga/scripts/radeon.start: line 15: echo: write error: Invalid argument
/etc/hprofile/profiles/vga/scripts/radeon.start: line 16: echo: write error: Invalid argument
(...)
|
|
You should be able to run `hprofile vga.radeon' and `hprofile vga.fglrx' of course (it hprofile is not broken.)
Now, those 2 faulty lines are easily corrected... I've just checked and it seems that extra editing is required: you should remove `device/' on line 15/16 because this subdirectory is removed in newer kernel. Like I've said, some profile (script) may be a little out dated... because the Linux kernel is in active development. So if you run into an issue like the previous, you could just fix them by those trivial checking & fix.
I cannot possibly guaranty the functionalities of those little scripts... it's included in hprofile tarball "as is", so, edit them to fit your needs.
So, go and experiment... and _do_ not hold back to post your findings... that I could possibly include in feature release of hprofile.
Luck!
| kon14 wrote: | | PS: What's the vim line in the end of the file? |
Just useful comment to have syntax highlighting & more when editing with vim. (It's handy in script like those without the first line being `#!/bin/$SHEL'.)
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/ |
|
| Back to top |
|
|
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Fri Jan 23, 2015 12:20 pm Post subject: |
|
|
NOTE: I've just released hprofile-[34].2.2 with a slight update/edit in vga profile and man page.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/ |
|
| Back to top |
|
|
kon14
n00b
Joined: 27 Nov 2014
Posts: 34
|
| Posted: Fri Jan 23, 2015 1:29 pm Post subject: |
|
|
| tclover wrote: | | kon14 wrote: | I installed version 3.2.1 from the overlay. Uncommented the lines in radeon.stop and tried again.
I was actually trying to start vga.fglrx/vga.radeon, though the profile names are vga.at/vga.xorg-x11, as with mere eselect opengl.
I can run hprofile vga.ati/xorg-x11 without it complaining, but lsmod shows that radeon is running anyway and so does uvesafb after switching back to radeon :S
Catalyst is still off. |
I am completly lost here... what are you talking about? |
I must have tried using a non-existent profile, though it didn't report its inexistence.
Nevermind that.
I commented the xvmc lines, hadn't searched for them in fglrx.
| tclover wrote: |
You should be able to run `hprofile vga.radeon' and `hprofile vga.fglrx' of course (it hprofile is not broken.)
Now, those 2 faulty lines are easily corrected... I've just checked and it seems that extra editing is required: you should remove `device/' on line 15/16 because this subdirectory is removed in newer kernel. Like I've said, some profile (script) may be a little out dated... because the Linux kernel is in active development. So if you run into an issue like the previous, you could just fix them by those trivial checking & fix.
|
The device directory inside /sys is either back in 3.18.3 or I somehow managed to write into the virtual filesystem myself during this session.
I'll find the appropriate file and write to it, though why do we even echo this profile? Catalyst overwrites the profile so we back it up?
In that case we can enter whatever profile we like.
EDIT: Also the kernel won't let root write into those /sys files. I'm not using sudo, though I still tried piping into tee and writing into the file.
I also tried running a new bash/sh and testing with my laptop. I must have edited the power settings in /sys before, but perhaps it was with a different kernel :S
Google didn't bring back anything useful. Can you write into those files in your setup? |
|
| Back to top |
|
|
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Fri Jan 23, 2015 4:01 pm Post subject: |
|
|
| kon14 wrote: | EDIT: Also the kernel won't let root write into those /sys files. I'm not using sudo, though I still tried piping into tee and writing into the file.
I also tried running a new bash/sh and testing with my laptop. I must have edited the power settings in /sys before, but perhaps it was with a different kernel :S
Google didn't bring back anything useful. Can you write into those files in your setup? |
Again, comment out to keep going... as you might have noticed, those lines set power management profile for radeon (not fglrx.) Try not to lose sight of what you're trying to do! Once, the main point is manageable, you can pick options later. Indeed, you have to have root privilege for those kind of things--as hprofile does, you should be running hprofile as root if you're not doing user profiles management.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/ |
|
| Back to top |
|
|
kon14
n00b
Joined: 27 Nov 2014
Posts: 34
|
| Posted: Fri Jan 23, 2015 4:25 pm Post subject: |
|
|
| tclover wrote: | | kon14 wrote: | EDIT: Also the kernel won't let root write into those /sys files. I'm not using sudo, though I still tried piping into tee and writing into the file.
I also tried running a new bash/sh and testing with my laptop. I must have edited the power settings in /sys before, but perhaps it was with a different kernel :S
Google didn't bring back anything useful. Can you write into those files in your setup? |
Again, comment out to keep going... as you might have noticed, those lines set power management profile for radeon (not fglrx.) Try not to lose sight of what you're trying to do! Once, the main point is manageable, you can pick options later. Indeed, you have to have root privilege for those kind of things--as hprofile does, you should be running hprofile as root if you're not doing user profiles management. |
I was actually surprised about it. Perhaps I didn't clarify myself. I'm not using sudo -> so there shouldn't be a need to pipe the echo command into tee path_to_file.
I am logged in as root and the kernel won't let me write into the file.
Since those lines aren't needed I'll move along and inspect this issue closer later on.
Now it all comes down to the module not being found no matter it's in place. |
|
| Back to top |
|
|
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Fri Jan 23, 2015 4:31 pm Post subject: |
|
|
| kon14 wrote: | I was actually surprised about it. Perhaps I didn't clarify myself. I'm not using sudo -> so there shouldn't be a need to pipe the echo command into tee path_to_file.
I am logged in as root and the kernel won't let me write into the file.
Since those lines aren't needed I'll move along and inspect this issue closer later on.
Now it all comes down to the module not being found no matter it's in place. |
Many files in VFS are not writable... even for root. You can check with something like `ls -l /path/to/dir'.
Just try to keep the bare minimum, namely, being able switch a profile (radeon/fglrx) with only the related module [un]loading commands. Once this is doable, you can think about other options.
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 4:46 pm Post subject: |
|
|
| tclover wrote: | | kon14 wrote: | I was actually surprised about it. Perhaps I didn't clarify myself. I'm not using sudo -> so there shouldn't be a need to pipe the echo command into tee path_to_file.
I am logged in as root and the kernel won't let me write into the file.
Since those lines aren't needed I'll move along and inspect this issue closer later on.
Now it all comes down to the module not being found no matter it's in place. |
Many files in VFS are not writable... even for root. You can check with something like `ls -l /path/to/dir'.
Just try to keep the bare minimum, namely, being able switch a profile (radeon/fglrx) with only the related module [un]loading commands. Once this is doable, you can think about other options.
Luck! |
I knew about some files being solely utilized by the kernel in /sys but I was astonished to find out those card profiles where included. I'm sure I've written to them before :S
I read my previous post concerning my fglrx module being there again and it's indeed there for 3.18.3, albeit not my current build!
Why wouldn't it though? I'm sure I tried rebuilding everything. Could the new configuration prevent make install from putting it there?
If so would putting it there myself work?
I'll try rebuilding it and see if it's there. Hopefully this should be trivial. |
|
| Back to top |
|
|
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Fri Jan 23, 2015 5:04 pm Post subject: |
|
|
| kon14 wrote: | I read my previous post concerning my fglrx module being there again and it's indeed there for 3.18.3, albeit not my current build!
Why wouldn't it though? I'm sure I tried rebuilding everything. Could the new configuration prevent make install from putting it there?
If so would putting it there myself work?
I'll try rebuilding it and see if it's there. Hopefully this should be trivial. |
It depends... where the module is installed: if it's in a directory used already by default kernel module, chances are that anything installed there will be wiped out before any subsequent `make modules_install' (in kernel sources directory.)
NOTE: `/lib/modules/$VERSION/video' should be fine. However, if the kernel was recompiled with different config file... so the extra module should.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/
Last edited by tclover on Fri Jan 23, 2015 5:05 pm; edited 1 time in total |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Desktop Environments
