Re: community/e-svn 51937-1 BROKEN? themes fail screen resolution fail etc...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



It would appear that on Sep 16, Nicky726 did say:

> Dne Čt 16. září 2010 06:27:23 Joe(theWordy)Philbrook napsal(a):
---<<snip>>---
> > 
> > I'll followup to this thread if one of AUR's themes works for me.
> > 			-or-
> > if e17 respects "xrandr" resolution settings...

I did followup with the info that some of the AUR themes worked for me and
that E17 was respecting the xrandr command...
> 
> This reminds me I did change screen resolution via an autorun script on E17 
> some time ago (when E17's resolution control showed only the default screen 
> resolution).
> 
> I can't find the script now, but simply running "xrandr -s 1024x768" from 
> terminal inside od E17 changes the resolution correctly. Running just "xrandr" 
> should give you the list of supported resolution, if the desired one is not 
> listed you have to add a modeline. When you have the correct xrandr call(s) 
> tested, you can automate it by creating say change-resolution.sh (should go in 
> your PATH I think):
> #!/bin/sh
> xrandr -s ...
> 
> which you then set up to autorun in control center -- aplications -- 
> aplication on start (hope I translated it correctly from my localization).

Thanks! And your right "xrandr -s 1024x768" is the correct command to set
a "1024x768" screen resolution. But when I ran "xrandr" with no argument I
found that it was the forth listed resolution thus since the alternative
form "xrandr -s <index>" starts with zero, I saved myself 7 keystrokes when
I originally added the command:
xrandr -s 3
to my xinitrc-e16 files that get copied to ~/.xinitrc when I choose e16
on one of my installed linux distros... 

I went with the .xinitrc method because when I used xrandr from inside an
already running e16 it worked except that the borders of any window I opened
cheerfully started or ended (or both) outside the new desktop area. By
running xrandr inside the .xinitrc it took effect just before e16 started,
and so new windows were by default sized and positioned inside the desktop
area.

Now it's fairly likely that by setting a script up in what in my e17's
localization is "menu->settings->settings panel->apps->startup applications"
would accomplish the same thing. But since I use startx rather then some
display manager to initialize X I'm used to the ~/.xinitrc method.

But I thank you for the clue. It could happen that the linux developers
might do something to make the use of display managers mandatory, then 
I'd have to try the autorun script method. Heck, Ubuntu kinda sorta have
done so already. In order to get a runlevel 3 startup with my *xubuntu
(*without having to wade through some gui, pop-up error menus) I had to
install a simplistic display manager (slim) which unlike gdm & kdm still
respected the debian method of:

=> update-rc.d -f foobar remove                                                         
=> update-rc.d foobar stop 20 2 3 4 5 .                                                 

If the rest of the linux distros (and available display managers) follow
ubuntu's (and gdm's) example I might have to give up on startx. Till then,
for me, it's the only wayto go...

-- 
|   ---   ___
|   <0>   <->     Joe (theWordy) Philbrook
|       ^              J(tWdy)P
|    ~\___/~      <<jtwdyp@xxxxxxxx>>

[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux