If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

lolsed: Get Rid Of Unsupported Hardware / Testing Only Watermark

This script is tested with ruby 1.8.7 and awk 4.0.0. Earlier/later versions may or may not work. Two important lessons about using this:

(1) Don't use it while in an X session running fglrx! You can use it if you're running vesa or the open source radeon driver, but if you're trying to patch the same version of fglrx that you're currently running in your session, your system will probably hang when you use this. The easiest way to fix this while still retaining an Xorg session is to edit xorg.conf to replace Driver "fglrx" with Driver "vesa". If you don't want to do that, just run "init 1" as root and you'll probably be dropped to a VT and Xorg will be killed (this is what we want).

(2) Don't use it if you don't get any watermark in your driver! This is only for getting rid of watermark in pre-release beta drivers, for example the recent build of 8.96 published for OpenCL 1.2 support (so you can actually enjoy using them), or getting rid of "Unsupported Hardware" bug in production drivers (because technically if you are able to start fglrx at all with your hardware, it shouldn't be displaying that; but sometimes very new hardware will encounter this bug).

Save this code as a script, make it executable and run it as root:

chmod +x lolsed.rb
./lolsed.rb
#append sudo to the previous command if you run Ubuntu/Debian and aren't in a # root shell

SPECIAL THANKS: Kano (for the original concept / binary hacking). I edited his script to make it work with recent fglrx by re-writing it in Ruby instead of bash (there were some escaping issues with his bash script).

Great job with the script. I recently had some challenges in making it work, as (for reasons beyond my ken) there were 2 fglrx_drv.so; one in
'/usr/lib/xorg/modules/drivers/fglrx_drv.so'
and another in
'/usr/lib/fglrx/xorg/modules/drivers/fglrx_drv.so'

not entirely sure why this is, as my wife's laptop (running Mint 12) took the bash script with no problem, but my laptop running Lubuntu 12.04 had the second copy.

Is there a way to add some additional function to the ruby script? My bash skills are decent, but am not so sure about ruby. Additional features that would be nice:
1. find additional common instances of fglrx_drv.so
2. backup the file(s) to /tmp (or wherever) using tar
3. apply the awk to the files

Again, amazing job on the script, as it gives you an interactive show as to what is happening, or what failed. Additional features would make it a bit more comfortable for paranoid folks, or for the next time the location of the .so file changes

Great job with the script. I recently had some challenges in making it work, as (for reasons beyond my ken) there were 2 fglrx_drv.so; one in
'/usr/lib/xorg/modules/drivers/fglrx_drv.so'
and another in
'/usr/lib/fglrx/xorg/modules/drivers/fglrx_drv.so'

not entirely sure why this is, as my wife's laptop (running Mint 12) took the bash script with no problem, but my laptop running Lubuntu 12.04 had the second copy.

Is there a way to add some additional function to the ruby script? My bash skills are decent, but am not so sure about ruby. Additional features that would be nice:
1. find additional common instances of fglrx_drv.so
2. backup the file(s) to /tmp (or wherever) using tar
3. apply the awk to the files

Again, amazing job on the script, as it gives you an interactive show as to what is happening, or what failed. Additional features would make it a bit more comfortable for paranoid folks, or for the next time the location of the .so file changes

It wasn't really designed with user friendliness in mind, but considering your request I might work on it a little bit if I have some spare time (no promises though).

I agree that the safety issue should be somewhat more of a priority than it has been, in other words I should take a backup of the file first. But in my experience the commands either fail entirely or they succeed and the modifications are successful. Of course if you modify the currently running fglrx_drv that the X server is using, you're going to hang the system, and who knows what might happen then... it might only get partway through, or it might not sync all the changes to disk... hard to say.

BTW, you can supply the name of the fglrx_drv.so file to modify on the command line, so you don't have to alter the script in order to specify one or several fglrx_drv.so files to process... you can just call the script as many times as necessary on each of the files. Careful not to call it on anything not named "fglrx_drv.so" though because all bets are off if you do!

As for continued enhancements to the script, I probably won't make it too fancy, because I'm not a Ruby whiz either... in fact I don't really like Ruby that much except for its niche usage for scripts that are painful to write in bash and too verbose in a real language like C/Vala/Java/etc. I'm not a scripting language fan in general because of the lack of compile-time type checking and IDEs with good code completion, but my main goal with lolsed was to take Kano's original work in bash and overcome a limitation I'd encountered with it (namely that it fails if there are certain sequences of bytes in the input file; worse, the input file can essentially lead to arbitrary code injection into the script, which is never a good thing to mix with root privileges...).

BTW, the script itself doesn't use the sed command, which makes the name of it, "lolsed", a kind of humorous misnomer. In fact, one of the main functions of Kano's original script that my script replaces is the sed command, instead opting to use Ruby's built-in "gsub!" method on a Ruby String in memory, rather than modifying the file in-place. So you could say that the script is named lolsed because I was laughing at how bad the sed command was operating; specifically, that ATI could design their binary in a way as to inject arbitrary commands into the interpreter if they knew that we were modifying their binaries this way, and do something nasty like delete all your files or send a message over the internet to ATI saying "Hi, I'm hacking your files!"

It wasn't really designed with user friendliness in mind, but considering your request I might work on it a little bit if I have some spare time (no promises though).

Wholly understood. I wind up assembling scripts quickly with KISS in mind. 99/100, Simple (that makes sense to me) is not friendly to the next guy that looks over what I did

BTW, you can supply the name of the fglrx_drv.so file to modify on the command line, so you don't have to alter the script in order to specify one or several fglrx_drv.so files to process... you can just call the script as many times as necessary on each of the files. Careful not to call it on anything not named "fglrx_drv.so" though because all bets are off if you do!

Tis pretty much what I wound up doing. In between my bonehead of forgetting to use "sudo", realizing the module was in use, changing the driver in xorg.conf between radeon and fglrx (to address the open file), yadda yadda yadda... I just wanted to make sure to say "Thank you", as you saved me a fair amount of my failing sanity, as well as see if there was a possibility for the next guy (who may not have the same range of experience) to give up when they run it, and "LULZ! UR SCRIPT SUX!!!!!!!111one". Of course, the true fix of all of this is for AMD to do away with the bloody watermark, and come up with a better means of notifying the user, but I digress...

As for continued enhancements to the script, I probably won't make it too fancy, because I'm not a Ruby whiz either... in fact I don't really like Ruby that much except for its niche usage for scripts that are painful to write in bash and too verbose in a real language like C/Vala/Java/etc. I'm not a scripting language fan in general because of the lack of compile-time type checking and IDEs with good code completion, but my main goal with lolsed was to take Kano's original work in bash and overcome a limitation I'd encountered with it (namely that it fails if there are certain sequences of bytes in the input file; worse, the input file can essentially lead to arbitrary code injection into the script, which is never a good thing to mix with root privileges...)

Again, agreed. Had I more than just the ability to look at the script and divine some things, I would have made the modifications, made sure to credit you for the OG idea, and applied the usual warning of caveat emptor, and hoped someone found value in it. Shell scripts are very useful for some situations, but they are not replacements for the real languages.

Well sed has got problems with some kind of strings, this did not happen when i developed it. Recently i found out that there is rpl for exactly that purpose. So it could be done with rpl instead of sed as well, you just need to install it as it is not on a default installation. Hint:
Change