App windows won't fill screen in tahr 605 (Realy Solved)

[sheldonisaac]

Where is xinitrc, a search says it is in /root/.xinitrc. Even with the eye pressed I can't find it in root.

In Tahr 32-bit ver 6.0.6, it's

Code: Select all

ls -la /root/.xinitrc 
-rwxr-xr-x 1 root root 6261 Feb 20  2017 /root/.xinitrc

[number77]

Where is xinitrc, a search says it is in /root/.xinitrc. Even with the eye pressed I can't find it in root.

In Tahr 32-bit ver 6.0.6, it's

Code: Select all

ls -la /root/.xinitrc 
-rwxr-xr-x 1 root root 6261 Feb 20  2017 /root/.xinitrc

Sorry sheldonisaac that doesn't mean anything to me, my terminal skills very basic.

[theru]

It's strange that you can't see the file in rox. When you right click and choose display -> sort by name, do you see the file where you would expect it?

When you type the following command in a terminal:

Code: Select all

ls -a /root

you should see a list of all the files/folders in /root. The -a switch also reveals the hidden ones, just like the eye icon in rox.

Most gui programs allow you to open a file from a terminal. Here is an example:

Code: Select all

geany /root/.xinitrc

However this means that if you close the terminal by mistake it will also take the program down. This won't happen when you add a &

Code: Select all

geany /root/.xinitrc&

When you are already in the folder containing the file you won't need to type the full path.

[number77]

I am struggling to make a copy of xinitrc so sending you a copy may take some time.

[theru]

No worries. As far as I know the file xset.sh only gets modified when you use pupx and maybe some options from jwmdesk so it should be relatively safe.

I've noticed that "sort by name" can be interpreted in different ways.

In rox the files are simply sorted alphabetically whether they start with a dot or not.

On other places like the file selection dialog when you are for example adding an attachment the files starting with a dot are grouped separately when they are sorted by name. I have no idea why they are sorted differently but I can see how it can confuse some people.

Only a few extensions are allowed for forum attachments. In the section where you can add an attachment you see a link on the left named Allowed extensions and sizes. When you click on it you'll see a list of allowed extensions.

I can think of 2 ways to add an attachment:

One way is to copy the file to a name with an allowed extension like this:

Code: Select all

cp /root/.xinitrc /root/xinitrc.tar

In this example the copy doesn't start with a dot so it will hopefully be more visible.The copy isn't really a tar file but it is enough to allow it to upload.

Another way is to really make a tar file:

Code: Select all

cd /root
tar -cf xinitrc.tar .xinitrc

This creates an xinitrc.tar archive (-c) and adds .xinitrc to it (-f).

[Flash]

Or you can change the file extension to something the forum allows and explain in the post which kind of file it really is. Actually I've read that Linux pays no attention to filename extensions.

There is a 250 kB limit on attachments.

[theru]

With "change", do you mean "rename" or "copy"?

When I "forgot" to change .xinitrc back to it's original name and restarted xorg the pc shut down instead

[Flash]

Sorry, I should have said rename, not change.

So I was wrong about Linux not caring about the file name? Or is it just certain apps? In your case, it seems that Xorg was looking for a file with a certain name and couldn't find it, so it locked up. That would be different from what I meant, wouldn't it?

[theru]

I was curious about what would happen if .xinitrc wasn't found.

When I tried inserting the xrandr command closer to the end of the script xorg simply refused to start so I was surprised about the shutdown.

I understand enough about mp or nano to revert these changes without a gui but I don't think number77 would have been that lucky.

[number77]

Glad to hear it's working.

When you run xrandr you see a list of available resolutions with a * after the one the screen is currently set to. There is no * when the screen is disabled.

I have noticed that the file xset.sh is rewritten when you run menu -> desktop -> pupx set properties of x and change some settings there. While that won't happen often it still means it's a less than ideal place to make the settings permanent.

The xset.sh command is called by /root/.xinitrc. The xinitrc file is less likely to be rewritten unexpectedly. However you can't just insert the xrandr command anywhere so if you decide to try it it would be best to backup the file first.

The xset.sh command is only called once in xinitrc so it's easy to locate using the find command in a text editor. On my system it's this block of text:

Code: Select all

if [ -f /root/.xset.sh ];then
 #this is created by /usr/bin/pupx...
 eval "/root/.xset.sh"

Just above that entry the xrandr command can be safely inserted.

It will probably look like this:

Code: Select all

xrandr --output DP3 --off 

if [ -f /root/.xset.sh ];then
 #this is created by /usr/bin/pupx...
 eval "/root/.xset.sh"

Feel free to send me your xinitrc if you don't feel comfortable to make the changes yourself.

I gave up trying to make a copy of xinitrc and took the plunge and inserted your command xrandr --output DP3 --off in it and it now is able to go full screen at every boot.
Brilliant solution theru thank you for spending your time.
Also thank you to everyone else who helped on the way.
All the best.
number 77

[Flash]

Congratulations on sticking with it, number77, and thanks to everyone who contributed to this thread, even if your contribution didn't seem to lead to a solution.

[rufwoof]

I was curious about what would happen if .xinitrc wasn't found.

*nx convention is that /etc/X11/xinit/xinitrc is run (system wide default choice). For other *nx's typically xorg includes twm, xclock, xterm such that you end up at a twm gui desktop ... which is usually a black screen with a x as a cursor. In Puppy that's been stripped out to make things leaner.

[bigpup]

I wonder if it is as simple, as a bios setting, that would just turn off the dp3 port

It has been proven again!
Read my signature statement.

Not too bad
Only took 5 pages of posts, to get the needed clue

Thanks for sticking with Puppy and solving the problem!!!

[theru]

The bios is a strong maybe but number77 seemed to be unfamiliar with text based interfaces so I tried to stay in a gui environment as much as possible.

But this experience did motivate me to take precautions should I find myself being stuck without a gui. I installed midnight commander so I'll have an easier time moving around.

While I wouldn't recommend it to a beginner I do believe it's possible even for a beginner to learn how to move around and do some basic file manipulation. It also has a menu and, when run in a gui, can also be controlled with the mouse.