My experience is that by default the same output is mirrored on both screens but the windows won't expand beyond the borders of the smaller screen.

Assuming the DP3 entry is a false positive it's easy to turn it off:

Code:

xrandr --output DP3 --off

This should turn off the fake screen. It can be checked by running xrandr without any options.

After that all that's left to do is to restart the window manager.

Assuming you are using jwm:

Code:

jwm -restart

A more generic way to restart the window manager is to go to the logout screen and click on Restart window manager.

All new windows opened after this point should resize correctly.

These changes only last for the current session and are reverted every time the computer or xorg server is restarted. So it needs to be run when xorg server is started but before the window manager is loaded.

Since this command is basically a single line I found it better to add it to an existing script. I found a really short one that's called early on.

On my pc the script /root/.xset.sh (hidden file, click the eye icon to reveal) only contains one line:

Code:

xset m 20/10 4 c off r rate 660 25 s off -dpms

The only thing that needs to be done is adding a new line and type the following:

Code:

xrandr --output DP3 --off

When that's done the pc should behave normally every time it's booted.

It works 100%, I forgot to restart the windows manager. When I did everything full screen.
Thats brilliant theru thanks.
I just have to follow the instructions and make it permenant.
Thanks once more.

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:

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:

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.

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:

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:

cd /root
tar -cf xinitrc.tar .xinitrc

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

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?

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:

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:

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

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum