Trying to write script to change monitor rez and color depth
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Trying to write script to change monitor rez and color depth
I am trying to automate a video test process and some need help trying to script this.
I am auto logging on as a user into run level 5 and I need a script that can change the current resoution and/or color depth then reboot the system then move on to the next rez/depth combination till I have run through all my options.
I am currently doing this in RHEL 4 but this also needs to work in RHEL 5, and SLES 10
So for example the steps the script needs to take is
1. set the resolution=640x480 depth=8
2. make a note in /var/log/messages then reboot, login as user x, sleep for X then...
3. set the resolution=640x480 depth=16
4. make a note in /var/log/messages then reboot, login as user x, sleep for X then...
5. set the resolution=640x480 depth=24
6. make a note in /var/log/messages then reboot, login as user x, sleep for X then...
7. resolution=800x600 depth=8
8. reboot and so on and so on...
I found the command "system-config-display" and I can set the rez to 640*480 but it seems that once I do no matter what I do I can not get it to go back up to say 1024x768 and my monitor config get lost so xrandr shows 640x480 is the highest rez supported.
I usually start out my test runs with the monitor set up for 1280x1024 but no matter what I do it seems that all I can do is change it to 600*480.
Can any one offer and advice as to why I loose my config or if there is al better way to script this.
I am not really sure if I am going down the right path here as I normally work with windows.
It's part of a test I am doing for video driver support.
Since this needs to be done on multiple machines and os builds I am looking for an automated way to do the testing then I can look at the logs once it is done going through all the video options.
What I and probably Tinkster don't understand is why the heck do you need to go through that cycle of reboot/login annoyance, and what benefit are you going to get out of that. You might just need to choose the correct driver and configure some modelines, at most.
Instead of doing such creative things, I'd start by looking as /var/log/Xorg.0.log. Take a look there, see what driver is being used and which modes are detected as valid, if there's any error or warning in the server, it must be there. Also revise the output for dmesg, if you are using fglrx or nvidia drivers and they fail for some reason and crash, it will also be there.
The reason for all this is that these are beta OS'es and drivers and I have to validate them using the multiple settings to simulate what an end user might do and then analyze the results.
At the moment I am having to do each iteration by hand and it's getting very tiresome and I am sure there has to be a way to script the test, I am just not sure how to go about it. It also does not help that I am a windows user who is trying to learn more Linux so I have that barrier to overcome as well.
The reason for all this is that these are beta OS'es and drivers and I have to validate them using the multiple settings to simulate what an end user might do and then analyze the results.
At the moment I am having to do each iteration by hand and it's getting very tiresome and I am sure there has to be a way to script the test, I am just not sure how to go about it. It also does not help that I am a windows user who is trying to learn more Linux so I have that barrier to overcome as well.
Thanks...
Any regular user, nowadays, will use xrandr (or or any graphical frontend to it), to change the resolution. Users are not usually going to edit xorg, then reboot. There's nothing wrong in doing so, but changing on the fly with xrandr is just faster and more convenient, when possible.
Plus, your test approach seems a weird thing to do, when you first should be solving the real problem, whatever it is, with your limitations in the resolution. I'd suggest you do that first, but choice is yours of course.
If you want to do a script to modify xorg.conf and set a new resolution, no one stops you from doing so. But this is going to be an overkill. You would need to write something (simple bash, sed or awk should work) to parse xorg.conf, and go cycling all the resolutions each time, then you need a way to identify whether the resolution worked or not, and that's not an easy one. Then you need to log it somewhere, and /var/log/messages as you said is not a good place, better use any other place that's more isolated from all the rest of system logs. A lot of work, with no objective in mind if you ask me.
Still, I don't get what you are trying to do, and what do you want to test. If the systems are well configured, any resolution the user choose will work, if they are not configured in a right way, then this whole thing is pointless, and they just need to be configured.
Maybe if you describe what you do manually we might get a better understanding on what your purpose is. You described the procedure in the first post, but you are not telling us what kind of analysis or examination do you do after each step, what are you exactly looking for?
The test I am doing is to verify functionality with different video settings.
The manual steps I am trying to script are:
1. Select "Applications" on the start menu, select "System Settings", and then "Display'.
2. From the Display Settings window, select the Hardware tab. Verify the Monitor Type and Video Card are correct for the system. If not correct, change Monitor Type and Video Card to correct settings.
3. Select the Settings tab. Change resolution and color depth settings from current settings (to other supported settings) using the drop down menus.
4. Apply the changes, then restart the OS and login.
5. Review dmesg and /var/log/messages to confirm there are no errors or fault conditions reported.
6. Repeat steps for all supported resolutions and color depths.
I can figure out the logging logic but for now I am just trying to figure out how simulate these color and resolution changes via a script.
The main problem with what you do is that it can't be worded easily on a semantic that matches the linux one, for example:
Quote:
Originally Posted by perlabsrat
2. From the Display Settings window, select the Hardware tab. Verify the Monitor Type and Video Card are correct for the system. If not correct, change Monitor Type and Video Card to correct settings.
How do you determine what's correct, and what isn't? For this, you would need routines to autodetect the hardware, and that assuming that your hardware is cooperative. So, you have to resort to human intervention here. I also wonder (forgive me, but I am not a Red Hat user) if your redhat configurator really offers you options that won't work on your system. Nowadays the hardware should be autodetected for the most part, and video cards and monitors are common enough.
Quote:
5. Review dmesg and /var/log/messages to confirm there are no errors or fault conditions reported.
This is a tricky one. I mean, if the X server doesn't boot then that's a concrete thing that can be detected. But if it does boot BUT doesn't behave like you expect, only a human can tell, unless there's something very concrete on the logs that allow you to identify that circumstance.
Quote:
3. Select the Settings tab. Change resolution and color depth settings from current settings (to other supported settings) using the drop down menus.
6. Repeat steps for all supported resolutions and color depths.
This would just involve using xrandr to get or set the modes, which is -I guess- what your graphical frontend does anyway.
I have a couple of questions. Forgive me if this has been resolved above but I can't find it right now: why do you think that xrandr is not a valid tool for your test, and why do you think you need to reboot after each resolution change?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.