Re: [gentoo-user] Library file formats
On Fri, 16 Oct 2009 14:10:22 +0200, Volker Armin Hemmann wrote: eix could have told you that. or emerge -s My point was that using eix is faster than posting to the list and awaiting a reply. The same is not necessarily true of emerge -s :( -- Neil Bothwick Politicians are like nappies Both should be changed regularly, and for the same reason signature.asc Description: PGP signature
Re: [gentoo-user] Library file formats
On Samstag 17 Oktober 2009, Neil Bothwick wrote: On Fri, 16 Oct 2009 14:10:22 +0200, Volker Armin Hemmann wrote: eix could have told you that. or emerge -s My point was that using eix is faster than posting to the list and awaiting a reply. The same is not necessarily true of emerge -s :( depends on your harddisk and filesystem. emerge -s can be as fast as eix on my box. emerge -S on the other hand
Re: [gentoo-user] distcc: Am I doing this right
Am Freitag 16 Oktober 2009 20:34:17 schrieb Michael Sullivan:
On Fri, 2009-10-16 at 18:31 +0200, Matthias Krebs wrote:
Am Freitag 16 Oktober 2009 15:23:20 schrieb Michael Sullivan:
I think I've set up distcc correctly, but I keep seeing a whole bunch
of messages like this:
distcc[24416] (dcc_writex) ERROR: failed to write: Connection reset by
peer
Is this normal? Is there anything I can do to prevent this from
happening?
-Michael Sullivan-
Well, if distcc does not see the other hosts it says somethind along the
lines failed to distribute, compiling locally instead
Looks more like a permission problem.
You did adjust /etc/conf.d/distccd, did you ?
Especially the network settings should allow your local network:
DISTCCD_OPTS=${DISTCCD_OPTS} --allow 192.168.1.0/24
Do I put that line on the slow machine or the fast one?
You need to put it on all hosts you have configured for usage.
distcc-config --get-hosts
shows you this hosts, but you have to configure them first with
distcc-config --set-hosts
It's all explained here : http://www.gentoo.org/doc/en/distcc.xml
Re: [gentoo-user] Library file formats
On Sat, 17 Oct 2009 11:30:32 +0200, Volker Armin Hemmann wrote: My point was that using eix is faster than posting to the list and awaiting a reply. The same is not necessarily true of emerge -s :( depends on your harddisk and filesystem. emerge -s can be as fast as eix on my box. On a reasonably fast system (dual core 64 bit with RAID5 over SATA2): eix lafilefixer 0.03s user 0.01s system 13% cpu 0.288 total emerge -s lafilefixer 1.37s user 0.19s system 63% cpu 2.460 total almost ten times as long. On a much slower system, Dell Mini 10: eix lafilefixer 0.17s user 0.05s system 17% cpu 1.251 total emerge -s lafilefixer 8.64s user 1.46s system 42% cpu 23.803 total Nearer twenty times as long. So the conclusion is that if you spend enough on hardware, emerge -s is only ten times slower than eix :-O -- Neil Bothwick Press any key... no, no, no, NOT THAT ONE! signature.asc Description: PGP signature
Re: [gentoo-user] distcc: Am I doing this right
On Sat, 2009-10-17 at 12:48 +0200, Matthias Krebs wrote:
Am Freitag 16 Oktober 2009 20:34:17 schrieb Michael Sullivan:
On Fri, 2009-10-16 at 18:31 +0200, Matthias Krebs wrote:
Am Freitag 16 Oktober 2009 15:23:20 schrieb Michael Sullivan:
I think I've set up distcc correctly, but I keep seeing a whole bunch
of messages like this:
distcc[24416] (dcc_writex) ERROR: failed to write: Connection reset by
peer
Is this normal? Is there anything I can do to prevent this from
happening?
-Michael Sullivan-
Well, if distcc does not see the other hosts it says somethind along the
lines failed to distribute, compiling locally instead
Looks more like a permission problem.
You did adjust /etc/conf.d/distccd, did you ?
Especially the network settings should allow your local network:
DISTCCD_OPTS=${DISTCCD_OPTS} --allow 192.168.1.0/24
Do I put that line on the slow machine or the fast one?
You need to put it on all hosts you have configured for usage.
distcc-config --get-hosts
shows you this hosts, but you have to configure them first with
distcc-config --set-hosts
It's all explained here : http://www.gentoo.org/doc/en/distcc.xml
I read the guide when I first set up distcc, but it didn't provide
enough detail for me to understand. I have two computers, a slow one
and a fast one. I would like the fast one to assist the slow one. The
fast machine's IP is 192.168.1.2, and the slow is 192.168.1.4. On the
fast one, I'm running /etc/init.d/distccd and it's /etc/conf.d/distccd
looks like this:
carter ~ # cat /etc/conf.d/distccd
# /etc/conf.d/distccd: config file for /etc/init.d/distccd
DISTCCD_OPTS=
# this is the distccd executable
DISTCCD_EXEC=/usr/bin/distccd
# this is where distccd will store its pid file
DISTCCD_PIDFILE=/var/run/distccd/distccd.pid
# set this option to run distccd with extra parameters
# Default port is 3632. For most people the default is okay.
DISTCCD_OPTS=${DISTCCD_OPTS} --port 3632
# Logging
# You can change some logging options here:
# --log-file FILE
# --log-level LEVEL [critical,error,warning, notice, info, debug]
#
# Leaving --log-file blank will log to syslog
# example: --log-file /dev/null --log-level warning
# example: --log-level critical
DISTCCD_OPTS=${DISTCCD_OPTS} --log-level critical
# SECURITY NOTICE:
# It is HIGHLY recomended that you use the --listen option
# for increased security. You can specify an IP to permit connections
# from or a CIDR mask
# --listen accepts only a single IP
# --allow is now mandatory as of distcc-2.18.
# example: --allow 192.168.0.0/24
# example: --allow 192.168.0.5 --allow 192.168.0.150
# example: --listen 192.168.0.2
DISTCCD_OPTS=${DISTCCD_OPTS} --allow 192.168.1.0/24
#DISTCCD_OPTS=${DISTCCD_OPTS} --listen 192.168.0.2
# set this for niceness
# Default is 15
DISTCCD_OPTS=${DISTCCD_OPTS} -N 15
There's no firewall on either.
The slow machine is also running /etc/init.d/distccd.
It's /etc/conf.d/distccd looks like this:
catherine ~ # cat /etc/conf.d/distccd
# /etc/conf.d/distccd: config file for /etc/init.d/distccd
DISTCCD_OPTS=
# this is the distccd executable
DISTCCD_EXEC=/usr/bin/distccd
# this is where distccd will store its pid file
DISTCCD_PIDFILE=/var/run/distccd/distccd.pid
# set this option to run distccd with extra parameters
# Default port is 3632. For most people the default is okay.
DISTCCD_OPTS=${DISTCCD_OPTS} --port 3632
# Logging
# You can change some logging options here:
# --log-file FILE
# --log-level LEVEL [critical,error,warning, notice, info, debug]
#
# Leaving --log-file blank will log to syslog
# example: --log-file /dev/null --log-level warning
# example: --log-level critical
DISTCCD_OPTS=${DISTCCD_OPTS} --log-level info
--log-file /var/log/distccd
# SECURITY NOTICE:
# It is HIGHLY recomended that you use the --listen option
# for increased security. You can specify an IP to permit connections
# from or a CIDR mask
# --listen accepts only a single IP
# --allow is now mandatory as of distcc-2.18.
# example: --allow 192.168.0.0/24
# example: --allow 192.168.0.5 --allow 192.168.0.150
DISTCCD_OPTS=${DISTCCD_OPTS} --allow 192.168.1.0/24
#DISTCCD_OPTS=${DISTCCD_OPTS} --listen 192.168.0.2
# set this for niceness
# Default is 15
DISTCCD_NICE=15
Is this right?
Re: [gentoo-user] distcc: Am I doing this right
Michael Sullivan writes:
It's all explained here : http://www.gentoo.org/doc/en/distcc.xml
I read the guide when I first set up distcc, but it didn't provide
enough detail for me to understand. I have two computers, a slow one
and a fast one. I would like the fast one to assist the slow one. The
fast machine's IP is 192.168.1.2, and the slow is 192.168.1.4. On the
fast one, I'm running /etc/init.d/distccd and it's /etc/conf.d/distccd
looks like this:
[...]
# Logging
# You can change some logging options here:
# --log-file FILE
# --log-level LEVEL [critical,error,warning, notice, info, debug]
#
# Leaving --log-file blank will log to syslog
# example: --log-file /dev/null --log-level warning
# example: --log-level critical
DISTCCD_OPTS=${DISTCCD_OPTS} --log-level critical
Until all is running fine, I suggest setting this to info or debug instead.
DISTCCD_OPTS=${DISTCCD_OPTS} --allow 192.168.1.0/24
Yup.
The slow machine is also running /etc/init.d/distccd.
That does no harm, but is not necessary unless you also want the slow
machine to help the fast one.
Is this right?
Looks good to me.
Did you activate distcc on the slow client with 'distcc-config --set-hosts
192.168.1.2'? This tells that all compilations should be done on the fast
machine. If you like the slow machine to also do some of the work, the
command could look like this: 'distcc-config --set-hosts 192.168.1.2
192.168.1.4/1', meaning that the slow one does one compilation at the time,
while for the fast one there is no limit.
Adjust your MAKEOPTS in /etc/make.conf to something like the total number of
cores plus one. And be sure you have distcc in your FEATURES.
Emerge something, and watch for failed to distribute, compiling locally
instead error messages in the emerge output. If there are none, distcc
seems to work.
And watch syslog on the fast machine, it should look like this (with log-
level set to notice):
Oct 17 15:30:43 [distccd] (dcc_job_summary) client: 192.168.2.35:38681
COMPILE_OK exit:0 sig:0 core:0 ret:0 time:1295ms x86_64-pc-linux-gnu-gcc
/var/tmp/ccache/sbc_primit.tmp.tanja.26261.i
Wonko
Re: [gentoo-user] distcc: Am I doing this right
On Sat, 2009-10-17 at 15:55 +0200, Alex Schuster wrote:
Michael Sullivan writes:
It's all explained here : http://www.gentoo.org/doc/en/distcc.xml
I read the guide when I first set up distcc, but it didn't provide
enough detail for me to understand. I have two computers, a slow one
and a fast one. I would like the fast one to assist the slow one. The
fast machine's IP is 192.168.1.2, and the slow is 192.168.1.4. On the
fast one, I'm running /etc/init.d/distccd and it's /etc/conf.d/distccd
looks like this:
[...]
# Logging
# You can change some logging options here:
# --log-file FILE
# --log-level LEVEL [critical,error,warning, notice, info, debug]
#
# Leaving --log-file blank will log to syslog
# example: --log-file /dev/null --log-level warning
# example: --log-level critical
DISTCCD_OPTS=${DISTCCD_OPTS} --log-level critical
Until all is running fine, I suggest setting this to info or debug instead.
DISTCCD_OPTS=${DISTCCD_OPTS} --allow 192.168.1.0/24
Yup.
The slow machine is also running /etc/init.d/distccd.
That does no harm, but is not necessary unless you also want the slow
machine to help the fast one.
Is this right?
Looks good to me.
Did you activate distcc on the slow client with 'distcc-config --set-hosts
192.168.1.2'? This tells that all compilations should be done on the fast
machine. If you like the slow machine to also do some of the work, the
command could look like this: 'distcc-config --set-hosts 192.168.1.2
192.168.1.4/1', meaning that the slow one does one compilation at the time,
while for the fast one there is no limit.
Adjust your MAKEOPTS in /etc/make.conf to something like the total number of
cores plus one. And be sure you have distcc in your FEATURES.
Emerge something, and watch for failed to distribute, compiling locally
instead error messages in the emerge output. If there are none, distcc
seems to work.
And watch syslog on the fast machine, it should look like this (with log-
level set to notice):
Oct 17 15:30:43 [distccd] (dcc_job_summary) client: 192.168.2.35:38681
COMPILE_OK exit:0 sig:0 core:0 ret:0 time:1295ms x86_64-pc-linux-gnu-gcc
/var/tmp/ccache/sbc_primit.tmp.tanja.26261.i
Wonko
I see those lines in /var/log/messages on the fast machine:
carter ~ # grep dcc_job_summary /var/log/*
grep: /var/log/mailman: No such file or directory
/var/log/messages:Oct 17 09:09:31 carter distccd[16791]:
(dcc_job_summary) client: 192.168.1.4:51319 COMPILE_OK exit:0 sig:0
core:0 ret:0 time:27537ms i686-pc-linux-gnu-gcc cmp_si.c
/var/log/messages:Oct 17 09:09:32 carter distccd[16792]:
(dcc_job_summary) client: 192.168.1.4:51320 COMPILE_OK exit:0 sig:0
core:0 ret:0 time:27637ms i686-pc-linux-gnu-gcc extract.c
/var/log/messages:Oct 17 09:09:32 carter distccd[16778]:
(dcc_job_summary) client: 192.168.1.4:51317 COMPILE_OK exit:0 sig:0
core:0 ret:0 time:27815ms i686-pc-linux-gnu-gcc agm.c
/var/log/messages:Oct 17 09:09:32 carter distccd[16790]:
(dcc_job_summary) client: 192.168.1.4:51318 COMPILE_OK exit:0 sig:0
core:0 ret:0 time:28005ms i686-pc-linux-gnu-gcc add1.c
/var/log/messages:Oct 17 09:12:06 carter distccd[16778]:
(dcc_job_summary) client: 192.168.1.4:51323 COMPILE_OK exit:0 sig:0
core:0 ret:0 time:143545ms i686-pc-linux-gnu-gcc dump.c
/var/log/messages:Oct 17 09:12:20 carter distccd[16790]:
(dcc_job_summary) client: 192.168.1.4:51324 COMPILE_OK exit:0 sig:0
core:0 ret:0 time:156242ms i686-pc-linux-gnu-gcc mul_ui.c
/var/log/messages:Oct 17 09:12:27 carter distccd[16792]:
(dcc_job_summary) client: 192.168.1.4:51322 COMPILE_OK exit:0 sig:0
core:0 ret:0 time:166479ms i686-pc-linux-gnu-gcc set_dfl_prec.c
/var/log/messages:Oct 17 09:12:39 carter distccd[16791]:
(dcc_job_summary) client: 192.168.1.4:51321 COMPILE_OK exit:0 sig:0
core:0 ret:0 time:184205ms i686-pc-linux-gnu-gcc print_raw.c
/var/log/messages:Oct 17 09:18:40 carter distccd[16792]:
(dcc_job_summary) client: 192.168.1.4:47096 COMPILE_OK exit:0 sig:0
core:0 ret:0 time:352543ms i686-pc-linux-gnu-gcc set_prec.c
/var/log/messages:Oct 17 09:18:40 carter distccd[16778]:
(dcc_job_summary) client: 192.168.1.4:47094 COMPILE_OK exit:0 sig:0
core:0 ret:0 time:375964ms i686-pc-linux-gnu-gcc mp_clz_tab.c
/var/log/messages:Oct 17 09:18:40 carter distccd[16790]:
(dcc_job_summary) client: 192.168.1.4:47095 COMPILE_OK exit:0 sig:0
core:0 ret:0 time:352688ms i686-pc-linux-gnu-gcc extract.c
/var/log/messages:Oct 17 09:18:40 carter distccd[16791]:
(dcc_job_summary) client: 192.168.1.4:47097 COMPILE_OK exit:0 sig:0
core:0 ret:0 time:337705ms i686-pc-linux-gnu-gcc ui_div.c
/var/log/messages:Oct 17 09:35:20 carter distccd[16790]:
(dcc_job_summary) client: 192.168.1.4:39724 COMPILE_OK exit:0 sig:0
core:0 ret:0 time:975864ms i686-pc-linux-gnu-gcc cmp_d.c
/var/log/messages:Oct 17 09:35:20 carter distccd[16791]:
(dcc_job_summary) client: 192.168.1.4:39727 COMPILE_OK exit:0 sig:0
core:0 ret:0 time:974682ms i686-pc-linux-gnu-gcc log1p.c
Re: [gentoo-user] Confusion
Am Samstag 17 Oktober 2009 17:54:49 schrieb econti: Now, to emerge akonadi-server, kcontrol I should downgrade all the qt-* to the 4.5.1 version. Says who? You can only tell what want's the downgrade when you add -t. akonadi-server needs some qt packages with a version =4.5.0 and kcontrol is a KDE 3.5 package which won't pull in QT 4 at all. Then to mask all the new kde4 packages, qt-*-4.5.2 and xulrunner. Is it right? How do come to this conclusion? Run your emerge command again with -t and you'll see clearer. Bye... Dirk signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] distcc: Am I doing this right
Michael Sullivan writes: I see those lines in /var/log/messages on the fast machine: carter ~ # grep dcc_job_summary /var/log/* grep: /var/log/mailman: No such file or directory /var/log/messages:Oct 17 09:09:31 carter distccd[16791]: (dcc_job_summary) client: 192.168.1.4:51319 COMPILE_OK exit:0 sig:0 Looks good. but I'm still seeing problems on the slow machine: libtool: compile: i686-pc-linux-gnu-gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LOCALE_H=1 -DHAVE_WCHAR_H=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_STDINT_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_LONG_LONG=1 -DHAVE_INTMAX_T=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_DENORMS=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_LDOUBLE_IEEE_EXT_LITTLE=1 -DLT_OBJDIR=\.libs/\ -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -O2 -march=i686 -ffloat-store -MT eint.lo -MD -MP -MF .deps/eint.Tpo -c eint.c -o eint.o /dev/null 21 make[1]: *** [exp3.lo] Killed make[1]: *** [exp.lo] Killed make[1]: *** [frac.lo] Killed make[1]: *** [get_d.lo] Killed make[1]: *** [get_exp.lo] Killed make[1]: *** [get_str.lo] Killed Processes are being killed because the slow machine simply does not have enough RAM to do what it's trying to do. Can I do anything about this beyond expanding the RAM? I'd like to finish this sometime this century, but processes keep getting killed. I shut down xdm before I started the emerge... What about adding swap space? Wonko
Re: [gentoo-user] distcc: Am I doing this right
On Sat, 2009-10-17 at 18:58 +0200, Alex Schuster wrote: Michael Sullivan writes: I see those lines in /var/log/messages on the fast machine: carter ~ # grep dcc_job_summary /var/log/* grep: /var/log/mailman: No such file or directory /var/log/messages:Oct 17 09:09:31 carter distccd[16791]: (dcc_job_summary) client: 192.168.1.4:51319 COMPILE_OK exit:0 sig:0 Looks good. but I'm still seeing problems on the slow machine: libtool: compile: i686-pc-linux-gnu-gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LOCALE_H=1 -DHAVE_WCHAR_H=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_STDINT_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_LONG_LONG=1 -DHAVE_INTMAX_T=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_DENORMS=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_LDOUBLE_IEEE_EXT_LITTLE=1 -DLT_OBJDIR=\.libs/\ -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -O2 -march=i686 -ffloat-store -MT eint.lo -MD -MP -MF .deps/eint.Tpo -c eint.c -o eint.o /dev/null 21 make[1]: *** [exp3.lo] Killed make[1]: *** [exp.lo] Killed make[1]: *** [frac.lo] Killed make[1]: *** [get_d.lo] Killed make[1]: *** [get_exp.lo] Killed make[1]: *** [get_str.lo] Killed Processes are being killed because the slow machine simply does not have enough RAM to do what it's trying to do. Can I do anything about this beyond expanding the RAM? I'd like to finish this sometime this century, but processes keep getting killed. I shut down xdm before I started the emerge... What about adding swap space? Wonko The problem is this: The machine only has one hard drive, and frequently we have to reboot it because the hard drive gets locked up trying to write and read from swap space...
Re: [gentoo-user] Library file formats
On Samstag 17 Oktober 2009, Neil Bothwick wrote: On Sat, 17 Oct 2009 11:30:32 +0200, Volker Armin Hemmann wrote: My point was that using eix is faster than posting to the list and awaiting a reply. The same is not necessarily true of emerge -s :( depends on your harddisk and filesystem. emerge -s can be as fast as eix on my box. On a reasonably fast system (dual core 64 bit with RAID5 over SATA2): eix lafilefixer 0.03s user 0.01s system 13% cpu 0.288 total emerge -s lafilefixer 1.37s user 0.19s system 63% cpu 2.460 total almost ten times as long. On a much slower system, Dell Mini 10: eix lafilefixer 0.17s user 0.05s system 17% cpu 1.251 total emerge -s lafilefixer 8.64s user 1.46s system 42% cpu 23.803 total Nearer twenty times as long. So the conclusion is that if you spend enough on hardware, emerge -s is only ten times slower than eix :-O and the difference is still just a second
[gentoo-user] sys-libs/db-4.7.25_p4 fetch failure
Hi group There was a hitch in the latest #emerge -uDN world. Here's the details: http://pastebin.com/m4726a7e3 Appears to be some kind of bug: http://bugs.gentoo.org/show_bug.cgi?id=285324 Anybody else had this problem? How should I proceed? Maxim
[gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2 bleeds off the edges
I normally stay logged in forever, even after updates. I'm both busy and lazy. However, the Xorg flurry seemed to have died down, so I took the plunge and rebooted. Oops. troll option=ignore It had not re-emerged xf86-input-* for me, a case that I think should be handled automatically -- I use a source distro because I want to be able to tweak it, not so that it can force me to do so at arbitrary, inconvenient and unpredictable intervals. /troll That was easily solved by searching my gmail archive, which in my case contains only the contents of technical mailing lists. Gmail seemed to me perfect for that. Others had already solved that problem, and I re-emerged. The bigger problem is that now Xorg is trying to display things off the left and right edges of my monitor. By adjusting the monitor I see that there are 24 pixels of stuff bleeding off the edge -- enough to lose a close box, for instance. My Xorg.conf does specify some details about the monitor, but no modeline. I had to put that stuff in there originally to get my preferred 1280x1024 resolution. Do I need to go back to the days of modlines? Xorg.conf is attached. ++ kevin -- Kevin O'Gorman, PhD xorg.conf Description: Binary data
Re: [gentoo-user] sys-libs/db-4.7.25_p4 fetch failure
On Samstag 17 Oktober 2009, Maxim Wexler wrote: Hi group There was a hitch in the latest #emerge -uDN world. Here's the details: http://pastebin.com/m4726a7e3 Appears to be some kind of bug: http://bugs.gentoo.org/show_bug.cgi?id=285324 Anybody else had this problem? How should I proceed? Maxim a) not use pastebin, but post the messages in your email? b) wait a couple of hours, emerge --sync and retry?
Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2 bleeds off the edges
On Samstag 17 Oktober 2009, Kevin O'Gorman wrote: I normally stay logged in forever, even after updates. I'm both busy and lazy. However, the Xorg flurry seemed to have died down, so I took the plunge and rebooted. Oops. troll option=ignore It had not re-emerged xf86-input-* for me, a case that I think should be handled automatically -- I use a source distro because I want to be able to tweak it, not so that it can force me to do so at arbitrary, inconvenient and unpredictable intervals. /troll gentoo is about 'doing it yourself' and 'emancipation of the user' and not about 'holding your hand'. It is not gentoo's fault if you act stupid. My Xorg.conf does specify some details about the monitor, but no modeline. I had to put that stuff in there originally to get my preferred 1280x1024 resolution. Do I need to go back to the days of modlines? Xorg.conf is attached. Section Monitor Identifier Monitor0 VendorName WDE ModelNameLCM-20v5 Option DPMS EndSection ?
Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2 bleeds off the edges
Am Samstag 17 Oktober 2009 19:21:46 schrieb Kevin O'Gorman: My Xorg.conf does specify some details about the monitor, but no modeline. I had to put that stuff in there originally to get my preferred 1280x1024 resolution. Do I need to go back to the days of modlines? Xorg.conf is attached. Did you try X -configure? Or even without xorg.conf? Bye... Dirk signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2 bleeds off the edges
On Sat, Oct 17, 2009 at 11:03 AM, Dirk Heinrichs dirk.heinri...@online.dewrote: Am Samstag 17 Oktober 2009 19:21:46 schrieb Kevin O'Gorman: My Xorg.conf does specify some details about the monitor, but no modeline. I had to put that stuff in there originally to get my preferred 1280x1024 resolution. Do I need to go back to the days of modlines? Xorg.conf is attached. Did you try X -configure? Or even without xorg.conf? Bye... Dirk I did. I was forced to by the behavior of X without them. That whole thing started out as the results of X -configure. -- Kevin O'Gorman, PhD
Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2bleeds off the edges
- Original Message - From: Kevin O'Gorman To: gentoo-user@lists.gentoo.org Sent: Saturday, October 17, 2009 2:42 PM Subject: Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2bleeds off the edges On Sat, Oct 17, 2009 at 11:03 AM, Dirk Heinrichs dirk.heinri...@online.de wrote: Am Samstag 17 Oktober 2009 19:21:46 schrieb Kevin O'Gorman: My Xorg.conf does specify some details about the monitor, but no modeline. I had to put that stuff in there originally to get my preferred 1280x1024 resolution. Do I need to go back to the days of modlines? Xorg.conf is attached. Did you try X -configure? Or even without xorg.conf? Bye... Dirk I did. I was forced to by the behavior of X without them. That whole thing started out as the results of X -configure. -- Kevin O'Gorman, PhD -- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.20/2441 - Release Date: 10/16/09 18:39:00 Just use gtf to get your desired modeline.
Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2 bleeds off the edges
On Sat, Oct 17, 2009 at 10:29 AM, Volker Armin Hemmann volkerar...@googlemail.com wrote: On Samstag 17 Oktober 2009, Kevin O'Gorman wrote: I normally stay logged in forever, even after updates. I'm both busy and lazy. However, the Xorg flurry seemed to have died down, so I took the plunge and rebooted. Oops. troll option=ignore It had not re-emerged xf86-input-* for me, a case that I think should be handled automatically -- I use a source distro because I want to be able to tweak it, not so that it can force me to do so at arbitrary, inconvenient and unpredictable intervals. /troll gentoo is about 'doing it yourself' and 'emancipation of the user' and not about 'holding your hand'. It is not gentoo's fault if you act stupid. My Xorg.conf does specify some details about the monitor, but no modeline. I had to put that stuff in there originally to get my preferred 1280x1024 resolution. Do I need to go back to the days of modelines? Xorg.conf is attached. Section Monitor Identifier Monitor0 VendorName WDE ModelNameLCM-20v5 Option DPMS EndSection ? Opinions differ about what constitutes stupidity. I'm not much interested in yours and I don't speak about mine, in part because neither one clarifies anything. Opinions about usefulness are another matter. Why not dispense with portage and have everyone compile their own from tarballs -- just publish a list of packages and patches; then you'd really not be holding hands. It seems to be a matter of degrees and judgement. Modifying the monitor section made no noticeable change. There's still a 24-pixel bleed off the right edge to begin with. I can fool with settings to make it bleed left instead, but there's no setting that affects pixel spacing. I like the cleaner monitor section, though. I'm back to thinking about modelines. Any better ideas? -- Kevin O'Gorman, PhD
Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2bleeds off the edges
On Sat, Oct 17, 2009 at 11:57 AM, Richard Marza richardmar...@optonline.net wrote: - Original Message - *From:* Kevin O'Gorman kogor...@gmail.com *To:* gentoo-user@lists.gentoo.org *Sent:* Saturday, October 17, 2009 2:42 PM *Subject:* Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2bleeds off the edges On Sat, Oct 17, 2009 at 11:03 AM, Dirk Heinrichs dirk.heinri...@online.de wrote: Am Samstag 17 Oktober 2009 19:21:46 schrieb Kevin O'Gorman: My Xorg.conf does specify some details about the monitor, but no modeline. I had to put that stuff in there originally to get my preferred 1280x1024 resolution. Do I need to go back to the days of modlines? Xorg.conf is attached. Did you try X -configure? Or even without xorg.conf? Bye... Dirk I did. I was forced to by the behavior of X without them. That whole thing started out as the results of X -configure. -- Kevin O'Gorman, PhD -- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.20/2441 - Release Date: 10/16/09 18:39:00 Just use gtf to get your desired modeline. That was a complete bust. I added the one I wanted and one for 1024x768 as a fallback. xdm restart and black screen forever, including trying to get to the fallback. Here's what gtf gave me: # 1280x1024 @ 60.00 Hz (GTF) hsync: 63.60 kHz; pclk: 108.88 MHz Modeline 1280x1024_60.00 108.88 1280 1360 1496 1712 1024 1025 1028 1060 -HSync +Vsync # 1024x768 @ 60.00 Hz (GTF) hsync: 47.70 kHz; pclk: 64.11 MHz Modeline 1024x768_60.00 64.11 1024 1080 1184 1344 768 769 772 795 -HSync +Vsync I put them in the Display section of Screen with depth 24. Comment them out and all is okay. -- Kevin O'Gorman, PhD
Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2 bleeds off the edges
On Saturday 17 October 2009 20:58:00 Kevin O'Gorman wrote: Modifying the monitor section made no noticeable change. There's still a 24-pixel bleed off the right edge to begin with. I can fool with settings to make it bleed left instead, but there's no setting that affects pixel spacing. I like the cleaner monitor section, though. I'm back to thinking about modelines. Any better ideas? I'd try adjust the frequencies first, then try modelines. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2bleeds off the edges
- Original Message - From: Kevin O'Gorman To: gentoo-user@lists.gentoo.org Sent: Saturday, October 17, 2009 2:58 PM Subject: Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2bleeds off the edges On Sat, Oct 17, 2009 at 10:29 AM, Volker Armin Hemmann volkerar...@googlemail.com wrote: On Samstag 17 Oktober 2009, Kevin O'Gorman wrote: I normally stay logged in forever, even after updates. I'm both busy and lazy. However, the Xorg flurry seemed to have died down, so I took the plunge and rebooted. Oops. troll option=ignore It had not re-emerged xf86-input-* for me, a case that I think should be handled automatically -- I use a source distro because I want to be able to tweak it, not so that it can force me to do so at arbitrary, inconvenient and unpredictable intervals. /troll gentoo is about 'doing it yourself' and 'emancipation of the user' and not about 'holding your hand'. It is not gentoo's fault if you act stupid. My Xorg.conf does specify some details about the monitor, but no modeline. I had to put that stuff in there originally to get my preferred 1280x1024 resolution. Do I need to go back to the days of modelines? Xorg.conf is attached. Section Monitor Identifier Monitor0 VendorName WDE ModelNameLCM-20v5 Option DPMS EndSection ? Opinions differ about what constitutes stupidity. I'm not much interested in yours and I don't speak about mine, in part because neither one clarifies anything. Opinions about usefulness are another matter. Why not dispense with portage and have everyone compile their own from tarballs -- just publish a list of packages and patches; then you'd really not be holding hands. It seems to be a matter of degrees and judgement. Modifying the monitor section made no noticeable change. There's still a 24-pixel bleed off the right edge to begin with. I can fool with settings to make it bleed left instead, but there's no setting that affects pixel spacing. I like the cleaner monitor section, though. I'm back to thinking about modelines. Any better ideas? -- Kevin O'Gorman, PhD -- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.20/2441 - Release Date: 10/16/09 18:39:00 Let's not rule-out the possibility that this might be an issue with a bad video card. I once thought I had a bad monitor because of horizontal and vertical bleeding and it turned out to be the video card. Try the modelines, if it does not work, swap video cards. Below is a section pertaining to modelines from my config. User gtf to generate proper modelines for your monitor. you can omit the identifier if you don't have a 22 inch minitor. Section Modes Identifier 16:10 # # Modelines for attached projectors. # Occasionally in town halls you meet ancient donated projectors # that can cope only with low resolutions. # # HorxVer @ clock hsync = clock * Vtotpclk = hsync * Htot # ModeLineHorxVer pclk Hor Hstart Hend Htot Ver Vstart Vend Vtot [Interlace] # # 640x480 @ 60.00 Hz (GTF) hsync: 31.50 kHz; pclk: 25.20 MHz # ModeLine640x480 25.20 640 664 760 800 480 491 493 525 # # 800x600 @ 60.00 Hz (GTF) hsync: 37.68 kHz; pclk: 39.79 MHz # ModeLine800x600 39.79 800 856 1040 1056 600 600 616 628 # # 1024x768 @ 60.00 Hz (GTF) hsync: 48.36 kHz; pclk: 65.00 MHz # ModeLine1024x768 65.00 1024 1032 1176 1344 768 771 777 806 # # 1024x768 @ 60.00 Hz (GTF) hsync: 29.97 kHz; pclk: 37.88 MHz # ModeLine1024x768 37.88 1024 1048 1208 1264 768 776 784 999 Interlace # # Modelines for the native 16:10 LCD screen. # # 1280x800 @ 60.00 Hz (GTF) hsync: 49.68 kHz; pclk: 83.46 MHz ModeLine1280x800 83.46 1280 1344 1480 1680 800 801 804 828 # # 1680x1050 @ 60.00 Hz (GTF) hsync: 63.84 kHz; pclk: 144.02 MHz Modeline 1680x1050_75.00 188.07 1680 1800 1984 2288 1050 1051 1054 1096 -HSync +Vsync EndSection
Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2 bleeds off the edges
On Sat, Oct 17, 2009 at 12:18 PM, Alan McKinnon alan.mckin...@gmail.comwrote: On Saturday 17 October 2009 20:58:00 Kevin O'Gorman wrote: Modifying the monitor section made no noticeable change. There's still a 24-pixel bleed off the right edge to begin with. I can fool with settings to make it bleed left instead, but there's no setting that affects pixel spacing. I like the cleaner monitor section, though. I'm back to thinking about modelines. Any better ideas? I'd try adjust the frequencies first, then try modelines. -- alan dot mckinnon at gmail dot com I'd try that too if I had a clue how to do it, let alone do it safely. Got any pointers to FMs? -- Kevin O'Gorman, PhD
Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2 bleeds off the edges
On Saturday 17 October 2009 21:26:41 Kevin O'Gorman wrote: On Sat, Oct 17, 2009 at 12:18 PM, Alan McKinnon alan.mckin...@gmail.comwrote: On Saturday 17 October 2009 20:58:00 Kevin O'Gorman wrote: Modifying the monitor section made no noticeable change. There's still a 24-pixel bleed off the right edge to begin with. I can fool with settings to make it bleed left instead, but there's no setting that affects pixel spacing. I like the cleaner monitor section, though. I'm back to thinking about modelines. Any better ideas? I'd try adjust the frequencies first, then try modelines. -- alan dot mckinnon at gmail dot com I'd try that too if I had a clue how to do it, let alone do it safely. Got any pointers to FMs? Safe frequency ranges are in the monitor's documentation. Do you have docs for your monitor (I'm using it's a CRT). You can safely reduce either horiz or vert range. As the electronics[1] age, the monitor's ability to correctly sync the start of the picture with the start of the display area deteriorates, especially at the upper bound. If reducing the upper bound of the horiz setting improves matters, that is indicative of this happening. [1] more specifically, electrolytic capacitors. They are temperature- sensitive. Silicon does not wear out as such. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2bleeds off the edges
On Sat, Oct 17, 2009 at 12:22 PM, Richard Marza richardmar...@optonline.net wrote: - Original Message - *From:* Kevin O'Gorman kogor...@gmail.com *To:* gentoo-user@lists.gentoo.org *Sent:* Saturday, October 17, 2009 2:58 PM *Subject:* Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2bleeds off the edges On Sat, Oct 17, 2009 at 10:29 AM, Volker Armin Hemmann volkerar...@googlemail.com wrote: On Samstag 17 Oktober 2009, Kevin O'Gorman wrote: I normally stay logged in forever, even after updates. I'm both busy and lazy. However, the Xorg flurry seemed to have died down, so I took the plunge and rebooted. Oops. troll option=ignore It had not re-emerged xf86-input-* for me, a case that I think should be handled automatically -- I use a source distro because I want to be able to tweak it, not so that it can force me to do so at arbitrary, inconvenient and unpredictable intervals. /troll gentoo is about 'doing it yourself' and 'emancipation of the user' and not about 'holding your hand'. It is not gentoo's fault if you act stupid. My Xorg.conf does specify some details about the monitor, but no modeline. I had to put that stuff in there originally to get my preferred 1280x1024 resolution. Do I need to go back to the days of modelines? Xorg.conf is attached. Section Monitor Identifier Monitor0 VendorName WDE ModelNameLCM-20v5 Option DPMS EndSection ? Opinions differ about what constitutes stupidity. I'm not much interested in yours and I don't speak about mine, in part because neither one clarifies anything. Opinions about usefulness are another matter. Why not dispense with portage and have everyone compile their own from tarballs -- just publish a list of packages and patches; then you'd really not be holding hands. It seems to be a matter of degrees and judgement. Modifying the monitor section made no noticeable change. There's still a 24-pixel bleed off the right edge to begin with. I can fool with settings to make it bleed left instead, but there's no setting that affects pixel spacing. I like the cleaner monitor section, though. I'm back to thinking about modelines. Any better ideas? -- Kevin O'Gorman, PhD -- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.20/2441 - Release Date: 10/16/09 18:39:00 Let's not rule-out the possibility that this might be an issue with a bad video card. I once thought I had a bad monitor because of horizontal and vertical bleeding and it turned out to be the video card. Try the modelines, if it does not work, swap video cards. Below is a section pertaining to modelines from my config. User gtf to generate proper modelines for your monitor. you can omit the identifier if you don't have a 22 inch minitor. Section Modes Identifier 16:10 # # Modelines for attached projectors. # Occasionally in town halls you meet ancient donated projectors # that can cope only with low resolutions. # # HorxVer @ clock hsync = clock * Vtotpclk = hsync * Htot # ModeLineHorxVer pclk Hor Hstart Hend Htot Ver Vstart Vend Vtot [Interlace] # # 640x480 @ 60.00 Hz (GTF) hsync: 31.50 kHz; pclk: 25.20 MHz # ModeLine640x480 25.20 640 664 760 800 480 491 493 525 # # 800x600 @ 60.00 Hz (GTF) hsync: 37.68 kHz; pclk: 39.79 MHz # ModeLine800x600 39.79 800 856 1040 1056 600 600 616 628 # # 1024x768 @ 60.00 Hz (GTF) hsync: 48.36 kHz; pclk: 65.00 MHz # ModeLine1024x768 65.00 1024 1032 1176 1344 768 771 777 806 # # 1024x768 @ 60.00 Hz (GTF) hsync: 29.97 kHz; pclk: 37.88 MHz # ModeLine1024x768 37.88 1024 1048 1208 1264 768 776 784 999 Interlace # # Modelines for the native 16:10 LCD screen. # # 1280x800 @ 60.00 Hz (GTF) hsync: 49.68 kHz; pclk: 83.46 MHz ModeLine1280x800 83.46 1280 1344 1480 1680 800 801 804 828 # # 1680x1050 @ 60.00 Hz (GTF) hsync: 63.84 kHz; pclk: 144.02 MHz Modeline 1680x1050_75.00 188.07 1680 1800 1984 2288 1050 1051 1054 1096 -HSync +Vsync EndSection None of the above are what I want. On another track, the Xorg log has a bunch of Modelines listed, but I can't see immediately which one it used. I'd like to start with that one and tweak it. Just the 1280x1024 ones are (II) MACH64(0): Modeline 1280x1024x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) MACH64(0): Modeline 1280x1024x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) MACH64(0): Modeline 1280x1024x60.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) I guess I'll try them to see if I can get a known starting point. -- Kevin O'Gorman, PhD
Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2bleeds off the edges
- Original Message - From: Kevin O'Gorman To: gentoo-user@lists.gentoo.org Sent: Saturday, October 17, 2009 3:26 PM Subject: Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2bleeds off the edges On Sat, Oct 17, 2009 at 12:18 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On Saturday 17 October 2009 20:58:00 Kevin O'Gorman wrote: Modifying the monitor section made no noticeable change. There's still a 24-pixel bleed off the right edge to begin with. I can fool with settings to make it bleed left instead, but there's no setting that affects pixel spacing. I like the cleaner monitor section, though. I'm back to thinking about modelines. Any better ideas? I'd try adjust the frequencies first, then try modelines. -- alan dot mckinnon at gmail dot com I'd try that too if I had a clue how to do it, let alone do it safely. Got any pointers to FMs? If you have a flat panel it will not mess up your monitor because they have safeguards against that and also modelines don't go in the monitor or screens section...they go in the modes section...did u try what i mentioned in my last post.
Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2 bleeds off the edges
On Sat, Oct 17, 2009 at 12:34 PM, Alan McKinnon alan.mckin...@gmail.comwrote: On Saturday 17 October 2009 21:26:41 Kevin O'Gorman wrote: On Sat, Oct 17, 2009 at 12:18 PM, Alan McKinnon alan.mckin...@gmail.comwrote: On Saturday 17 October 2009 20:58:00 Kevin O'Gorman wrote: Modifying the monitor section made no noticeable change. There's still a 24-pixel bleed off the right edge to begin with. I can fool with settings to make it bleed left instead, but there's no setting that affects pixel spacing. I like the cleaner monitor section, though. I'm back to thinking about modelines. Any better ideas? I'd try adjust the frequencies first, then try modelines. -- alan dot mckinnon at gmail dot com I'd try that too if I had a clue how to do it, let alone do it safely. Got any pointers to FMs? Safe frequency ranges are in the monitor's documentation. Do you have docs for your monitor (I'm using it's a CRT). You can safely reduce either horiz or vert range. As the electronics[1] age, the monitor's ability to correctly sync the start of the picture with the start of the display area deteriorates, especially at the upper bound. If reducing the upper bound of the horiz setting improves matters, that is indicative of this happening. [1] more specifically, electrolytic capacitors. They are temperature- sensitive. Silicon does not wear out as such. -- alan dot mckinnon at gmail dot com I have docs. They are not very informative. When I start it up, the left edge is fine, which is the sync edge. Because of that and because I can adjust positioning left and right, and because the problem arose abruptly with the reboot to a new Xorg, I rate the probability of hardware problems low (but not zero of course). It appears to be a problem of horizontal spacing of the pixels. At it stands there is not room for the last 24. -- Kevin O'Gorman, PhD
Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2bleeds off the edges
On Sat, Oct 17, 2009 at 12:39 PM, Richard Marza richardmar...@optonline.net wrote: - Original Message - *From:* Kevin O'Gorman kogor...@gmail.com *To:* gentoo-user@lists.gentoo.org *Sent:* Saturday, October 17, 2009 3:26 PM *Subject:* Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2bleeds off the edges On Sat, Oct 17, 2009 at 12:18 PM, Alan McKinnon alan.mckin...@gmail.comwrote: On Saturday 17 October 2009 20:58:00 Kevin O'Gorman wrote: Modifying the monitor section made no noticeable change. There's still a 24-pixel bleed off the right edge to begin with. I can fool with settings to make it bleed left instead, but there's no setting that affects pixel spacing. I like the cleaner monitor section, though. I'm back to thinking about modelines. Any better ideas? I'd try adjust the frequencies first, then try modelines. -- alan dot mckinnon at gmail dot com I'd try that too if I had a clue how to do it, let alone do it safely. Got any pointers to FMs? If you have a flat panel it will not mess up your monitor because they have safeguards against that and also modelines don't go in the monitor or screens section...they go in the modes section...did u try what i mentioned in my last post. It's a flat panel. I did not know what to do with your last post, as the modelines were not acceptable. The actual rates the monitor is showing now are 54.2KHz and 60.2Hz, which are well within specs. I chose the section from memory. In the pre-Xorg-pre-XFree days I seem to recall using different modelines at different depths. Modes section all by itself, not a subsection? I'll try that. -- Kevin O'Gorman, PhD
Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2bleeds off the edges
Original Message - From: Kevin O'Gorman To: gentoo-user@lists.gentoo.org Sent: Saturday, October 17, 2009 3:42 PM Subject: Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2bleeds off the edges On Sat, Oct 17, 2009 at 12:34 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On Saturday 17 October 2009 21:26:41 Kevin O'Gorman wrote: On Sat, Oct 17, 2009 at 12:18 PM, Alan McKinnon alan.mckin...@gmail.comwrote: On Saturday 17 October 2009 20:58:00 Kevin O'Gorman wrote: Modifying the monitor section made no noticeable change. There's still a 24-pixel bleed off the right edge to begin with. I can fool with settings to make it bleed left instead, but there's no setting that affects pixel spacing. I like the cleaner monitor section, though. I'm back to thinking about modelines. Any better ideas? I'd try adjust the frequencies first, then try modelines. -- alan dot mckinnon at gmail dot com I'd try that too if I had a clue how to do it, let alone do it safely. Got any pointers to FMs? Safe frequency ranges are in the monitor's documentation. Do you have docs for your monitor (I'm using it's a CRT). You can safely reduce either horiz or vert range. As the electronics[1] age, the monitor's ability to correctly sync the start of the picture with the start of the display area deteriorates, especially at the upper bound. If reducing the upper bound of the horiz setting improves matters, that is indicative of this happening. [1] more specifically, electrolytic capacitors. They are temperature- sensitive. Silicon does not wear out as such. -- alan dot mckinnon at gmail dot com I have docs. They are not very informative. When I start it up, the left edge is fine, which is the sync edge. Because of that and because I can adjust positioning left and right, and because the problem arose abruptly with the reboot to a new Xorg, I rate the probability of hardware problems low (but not zero of course). It appears to be a problem of horizontal spacing of the pixels. At it stands there is not room for the last 24. -- Kevin O'Gorman, PhD -- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.20/2441 - Release Date: 10/16/09 18:39:00 What type of monitor do you have? How old is it? What is the screen size? What exactly do you mean by bleeding edges? Does the gui scroll when you move you mouse towards the edges? is that what you mean by bleeding? Another thing; Do you have the monitor manual? It will tell you the proper H and V sync rates at certain resolutions. Are you sure it supports that resolution?
[gentoo-user] Re: Desperately seeking modelines; xorg 1.6.3.901-r2 bleeds off the edges
On 10/17/2009 10:21 AM, Kevin O'Gorman wrote: The bigger problem is that now Xorg is trying to display things off the left and right edges of my monitor. By adjusting the monitor I see that there are 24 pixels of stuff bleeding off the edge -- enough to lose a close box, for instance. Back in the bad old CRT days a tool like xvidtune was the way to find appropriate mode lines. I've not needed it since switching to newer monitors, thankfully, but it's still in portage. It even prints out the safe frequency ranges on the command-line if your monitor is new enough to supply that info.
Re: [gentoo-user] Desperately seeking modelines; xorg1.6.3.901-r2bleeds off the edges
- Original Message - From: Kevin O'Gorman To: gentoo-user@lists.gentoo.org Sent: Saturday, October 17, 2009 3:51 PM Subject: Re: [gentoo-user] Desperately seeking modelines; xorg1.6.3.901-r2bleeds off the edges On Sat, Oct 17, 2009 at 12:39 PM, Richard Marza richardmar...@optonline.net wrote: - Original Message - From: Kevin O'Gorman To: gentoo-user@lists.gentoo.org Sent: Saturday, October 17, 2009 3:26 PM Subject: Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2bleeds off the edges On Sat, Oct 17, 2009 at 12:18 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On Saturday 17 October 2009 20:58:00 Kevin O'Gorman wrote: Modifying the monitor section made no noticeable change. There's still a 24-pixel bleed off the right edge to begin with. I can fool with settings to make it bleed left instead, but there's no setting that affects pixel spacing. I like the cleaner monitor section, though. I'm back to thinking about modelines. Any better ideas? I'd try adjust the frequencies first, then try modelines. -- alan dot mckinnon at gmail dot com I'd try that too if I had a clue how to do it, let alone do it safely. Got any pointers to FMs? If you have a flat panel it will not mess up your monitor because they have safeguards against that and also modelines don't go in the monitor or screens section...they go in the modes section...did u try what i mentioned in my last post. It's a flat panel. I did not know what to do with your last post, as the modelines were not acceptable. The actual rates the monitor is showing now are 54.2KHz and 60.2Hz, which are well within specs. I chose the section from memory. In the pre-Xorg-pre-XFree days I seem to recall using different modelines at different depths. Modes section all by itself, not a subsection? I'll try that. -- Kevin O'Gorman, PhD -- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.20/2441 - Release Date: 10/16/09 18:39:00 If it was a subsection my post would have stated EndSubSection or something similar...Place the modes section after the InputDevice Section. Get your own modes...using gtf and slip them into the modes section like so: Section Modes Identifier 16:10 you modeline here EndSection But remember, you can leave out or specify the identifier ratios depending on whether it will work for you or not.
Re: [gentoo-user] sys-libs/db-4.7.25_p4 fetch failure
Volker Armin Hemmann wrote: On Samstag 17 Oktober 2009, Maxim Wexler wrote: Hi group There was a hitch in the latest #emerge -uDN world. Here's the details: http://pastebin.com/m4726a7e3 Appears to be some kind of bug: http://bugs.gentoo.org/show_bug.cgi?id=285324 Anybody else had this problem? How should I proceed? Maxim a) not use pastebin, but post the messages in your email? Unless they are seriously HUGE? b) wait a couple of hours, emerge --sync and retry? Agree with this part tho. Dale :-) :-)
Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2bleeds off the edges
On Sat, Oct 17, 2009 at 12:56 PM, Richard Marza richardmar...@optonline.net wrote: Original Message - *From:* Kevin O'Gorman kogor...@gmail.com *To:* gentoo-user@lists.gentoo.org *Sent:* Saturday, October 17, 2009 3:42 PM *Subject:* Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2bleeds off the edges On Sat, Oct 17, 2009 at 12:34 PM, Alan McKinnon alan.mckin...@gmail.comwrote: On Saturday 17 October 2009 21:26:41 Kevin O'Gorman wrote: On Sat, Oct 17, 2009 at 12:18 PM, Alan McKinnon alan.mckin...@gmail.comwrote: On Saturday 17 October 2009 20:58:00 Kevin O'Gorman wrote: Modifying the monitor section made no noticeable change. There's still a 24-pixel bleed off the right edge to begin with. I can fool with settings to make it bleed left instead, but there's no setting that affects pixel spacing. I like the cleaner monitor section, though. I'm back to thinking about modelines. Any better ideas? I'd try adjust the frequencies first, then try modelines. -- alan dot mckinnon at gmail dot com I'd try that too if I had a clue how to do it, let alone do it safely. Got any pointers to FMs? Safe frequency ranges are in the monitor's documentation. Do you have docs for your monitor (I'm using it's a CRT). You can safely reduce either horiz or vert range. As the electronics[1] age, the monitor's ability to correctly sync the start of the picture with the start of the display area deteriorates, especially at the upper bound. If reducing the upper bound of the horiz setting improves matters, that is indicative of this happening. [1] more specifically, electrolytic capacitors. They are temperature- sensitive. Silicon does not wear out as such. -- alan dot mckinnon at gmail dot com I have docs. They are not very informative. When I start it up, the left edge is fine, which is the sync edge. Because of that and because I can adjust positioning left and right, and because the problem arose abruptly with the reboot to a new Xorg, I rate the probability of hardware problems low (but not zero of course). It appears to be a problem of horizontal spacing of the pixels. At it stands there is not room for the last 24. -- Kevin O'Gorman, PhD -- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.20/2441 - Release Date: 10/16/09 18:39:00 What type of monitor do you have? How old is it? What is the screen size? What exactly do you mean by bleeding edges? Does the gui scroll when you move you mouse towards the edges? is that what you mean by bleeding? Another thing; Do you have the monitor manual? It will tell you the proper H and V sync rates at certain resolutions. Are you sure it supports that resolution? It's as listed in the xorg.conf above: I can be sure because it's Westinghouse. It's a flat-screen. It's a couple of years old, I guess. It's new enough to talk to X and report: (II) MACH64(0): clock: 121.8 MHz Image Size: 410 x 308 mm which agrees with my ruler. In inches a little over 16 x 12 visible. The video card is sending all 1280 dot columns. I have a control on the monitor called H position and I can scroll one pixel at a time to change which 1256 dot columns I want to see of the 1280 that are sent. The image does not scroll with mouse movement. I have the manual. You are way over-optimistic about its contents. I had no better luck on the web site. The limits I've posted were acquired by X from the monitor itself. The monitor did fine until I rebooted yesterday. Its on-screen display shows it thinks it's doing 1280x1...@60hz. It's close of course, but not quite there. -- Kevin O'Gorman, PhD
Re: [gentoo-user] Desperately seeking modelines; xorg1.6.3.901-r2bleeds off the edges
- Original Message - From: Kevin O'Gorman To: gentoo-user@lists.gentoo.org Sent: Saturday, October 17, 2009 4:11 PM Subject: Re: [gentoo-user] Desperately seeking modelines; xorg1.6.3.901-r2bleeds off the edges On Sat, Oct 17, 2009 at 12:56 PM, Richard Marza richardmar...@optonline.net wrote: Original Message - From: Kevin O'Gorman To: gentoo-user@lists.gentoo.org Sent: Saturday, October 17, 2009 3:42 PM Subject: Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2bleeds off the edges On Sat, Oct 17, 2009 at 12:34 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On Saturday 17 October 2009 21:26:41 Kevin O'Gorman wrote: On Sat, Oct 17, 2009 at 12:18 PM, Alan McKinnon alan.mckin...@gmail.comwrote: On Saturday 17 October 2009 20:58:00 Kevin O'Gorman wrote: Modifying the monitor section made no noticeable change. There's still a 24-pixel bleed off the right edge to begin with. I can fool with settings to make it bleed left instead, but there's no setting that affects pixel spacing. I like the cleaner monitor section, though. I'm back to thinking about modelines. Any better ideas? I'd try adjust the frequencies first, then try modelines. -- alan dot mckinnon at gmail dot com I'd try that too if I had a clue how to do it, let alone do it safely. Got any pointers to FMs? Safe frequency ranges are in the monitor's documentation. Do you have docs for your monitor (I'm using it's a CRT). You can safely reduce either horiz or vert range. As the electronics[1] age, the monitor's ability to correctly sync the start of the picture with the start of the display area deteriorates, especially at the upper bound. If reducing the upper bound of the horiz setting improves matters, that is indicative of this happening. [1] more specifically, electrolytic capacitors. They are temperature- sensitive. Silicon does not wear out as such. -- alan dot mckinnon at gmail dot com I have docs. They are not very informative. When I start it up, the left edge is fine, which is the sync edge. Because of that and because I can adjust positioning left and right, and because the problem arose abruptly with the reboot to a new Xorg, I rate the probability of hardware problems low (but not zero of course). It appears to be a problem of horizontal spacing of the pixels. At it stands there is not room for the last 24. -- Kevin O'Gorman, PhD -- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.20/2441 - Release Date: 10/16/09 18:39:00 What type of monitor do you have? How old is it? What is the screen size? What exactly do you mean by bleeding edges? Does the gui scroll when you move you mouse towards the edges? is that what you mean by bleeding? Another thing; Do you have the monitor manual? It will tell you the proper H and V sync rates at certain resolutions. Are you sure it supports that resolution? It's as listed in the xorg.conf above: I can be sure because it's Westinghouse. It's a flat-screen. It's a couple of years old, I guess. It's new enough to talk to X and report: (II) MACH64(0): clock: 121.8 MHz Image Size: 410 x 308 mm which agrees with my ruler. In inches a little over 16 x 12 visible. The video card is sending all 1280 dot columns. I have a control on the monitor called H position and I can scroll one pixel at a time to change which 1256 dot columns I want to see of the 1280 that are sent. The image does not scroll with mouse movement. I have the manual. You are way over-optimistic about its contents. I had no better luck on the web site. The limits I've posted were acquired by X from the monitor itself. The monitor did fine until I rebooted yesterday. Its on-screen display shows it thinks it's doing 1280x1...@60hz. It's close of course, but not quite there. -- Kevin O'Gorman, PhD -- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.20/2441 - Release Date: 10/16/09 18:39:00 So It's a flat-screen and not a flat panel lcd monitor? I think I'm beginning to understand your issue... setup the modelines like i told you and then check the monitor on-screen display settings. It seems it's not a modeline issue because modelines are primarily used to adjust
Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2bleeds off the edges
=== On Sat, 10/17, Kevin O'Gorman wrote: === It's a flat panel. === In that case I'd first try the monitor's own auto-adjust feature. Usually this is available by pressing some menu key on your monitor. If that doesn't work then make sure you have DDC support in your driver and enable it. You monitor is new enough that it should just work after being queried by DDC. -- Keith Dart -- -- Keith Dart ke...@dartworks.biz ===
SOLVED Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2bleeds off the edges
SOLVED On Sat, Oct 17, 2009 at 1:57 PM, Keith Dart ke...@dartworks.biz wrote: === On Sat, 10/17, Kevin O'Gorman wrote: === It's a flat panel. === In that case I'd first try the monitor's own auto-adjust feature. Usually this is available by pressing some menu key on your monitor. Okay, I just tried anything that might be such a feature. And the winner is reset. If that doesn't work then make sure you have DDC support in your driver and enable it. You monitor is new enough that it should just work after being queried by DDC. Good thing the above worked. I would have been a while figuring out how to do that one. -- Keith Dart -- -- Keith Dart ke...@dartworks.biz === -- Kevin O'Gorman, PhD
Re: [gentoo-user] Desperately seeking modelines; xorg 1.6.3.901-r2bleeds off the edges
SOLVED On Sat, Oct 17, 2009 at 1:57 PM, Keith Dart ke...@dartworks.biz wrote: === On Sat, 10/17, Kevin O'Gorman wrote: === It's a flat panel. === In that case I'd first try the monitor's own auto-adjust feature. Usually this is available by pressing some menu key on your monitor. If that doesn't work then make sure you have DDC support in your driver and enable it. You monitor is new enough that it should just work after being queried by DDC. -- Keith Dart -- -- Keith Dart ke...@dartworks.biz === -- Kevin O'Gorman, PhD
Re: [gentoo-user] OT: PC as USB client
Stroller has a cool idea: On 16 Oct 2009, at 12:58, Alex Schuster wrote: [I want a Linux PC to act as USB mass storage device] The hack that springs to mind is to see if you can pick up an Openmoko Freerunner with a broken screen. I'd guess you might be able to pick one up for as little as $50 or so. It needs no SIM - you just connect it to your office wifi instead, configure it to act as a mass storage device and share the appropriate directory by Samba or NFS or whatever. http://wiki.openmoko.org/wiki/Using_the_Neo_as_an_USB_Mass_storage_device Hey, this is a great idea! I'd never have thought about this. Configuring the device to boot up and automagically load the mass storage device kernel module - instead of the USB networking one, which is default - could be a bit tricky with a broken screen. But I doubt if you want to spend $200 on this, and I think that's about the going rate on a brand new Freerunner. Well, even $200 might be okay. I need this for a commercial project anyway, and I guess the customer would be happy not to have to move around USB sticks. But even better, I guess already have such a thing! My girl-friend got one a year ago, but was not happy with it. I just uses too much energy, has to be recharged every day. And there is some bug, when the battery is completely dead, it cannot be recharged - the moko needs another battery to start, then it can be exchanged with the dead one and recharged. Maybe there is s newer software, she hasn't looked for that for a while. And I thought the project is about dead anyway, but that may also be completely wrong. Anyway, the device would be already here, so I can play around with it. I do feel this is kinda a clumsy suggestion, to use a relatively expensive mobile phone - and such little of its functionality - for such an ostensibly-simple task. Clumsy, but also geeky :) I like it. There must be other Linux-based devices which will pretend to be mass storage devices, and I wouldn't be at all surprised if some of them were quite cheap and readily available. But I have no idea what they might be. There are many Linux-based handhelds or MP3 players, but I did not find such thing as a PCI card with USB peripheral hardware. At least now I know that an normal PC just cannot be a peripheral, its USB controller can work in host mode only. Thanks again! Wonko
[gentoo-user] [OT Xfce4/KDE] A URL aware applet
I once was a KDE desktop user... Lasted quite a while. But over time I went to Xfce4 Been using it now a good while, but one applet from KDE is sorely missed. There was some kind of panel applet, that was URL aware. Any time you highlighted text that looked like some kind of URL, a dialog window would open and offer to open it with whatever application normally opened such a URL. You might highlight a URL in a man page, text file, or even in the scrollback buffer and the dialog would be right there offering to open it. I wondered if there is anything like that for Xfce and if anyone knows what that applet it? I am awaiting an answer from Xfce user list on the same question.
[gentoo-user] livedvd v10.1 on eee PC
Hi group, I'd like to hear of peoples' experiences with the gentoo-livedvd-10.1 especially on the eee PC. In my case(asus 900a), whether I use startx at the boot prompt or let xdm start by default, the X window starts to open and I see a glimpse of the desktop but then the screen goes black and flickers and just the outline of the mouse cursor is visible. If I switch to a console and try to write a command I have to be fast because log messages are being re-directed intermittently from F12 and just pop up on the screen. But livedvd boots ok in my desktop. The log stays where it's supposed to be. Could it be the limited capability of the video chip in the eee? But that doesn't explain the log bleeding over into the console. PC and eee both have 1G ram, FWIW Maxim
Re: [gentoo-user] livedvd v10.1 on eee PC
On 10/17/2009 07:55 PM, Maxim Wexler wrote: In my case(asus 900a), whether I use startx at the boot prompt or let xdm start by default, the X window starts to open and I see a glimpse of the desktop but then the screen goes black and flickers and just the outline of the mouse cursor is visible. If I switch to a console and try to write a command I have to be fast because log messages are being re-directed intermittently from F12 and just pop up on the screen. Are you getting squashfs errors? Try intercepting the login screen and changing to a different desktop. In my case with the multilib livecd on two multicore PCs, one Intel, and one AMD, there seemed to be some interaction between KDE4 and squashfs. Gnome, Xfe, and I assume others, work fine.
Re: [gentoo-user] livedvd v10.1 on eee PC
Maxim Wexler wrote: Hi group, I'd like to hear of peoples' experiences with the gentoo-livedvd-10.1 especially on the eee PC. In my case(asus 900a), whether I use startx at the boot prompt or let xdm start by default, the X window starts to open and I see a glimpse of the desktop but then the screen goes black and flickers and just the outline of the mouse cursor is visible. If I switch to a console and try to write a command I have to be fast because log messages are being re-directed intermittently from F12 and just pop up on the screen. But livedvd boots ok in my desktop. The log stays where it's supposed to be. Could it be the limited capability of the video chip in the eee? But that doesn't explain the log bleeding over into the console. PC and eee both have 1G ram, FWIW Maxim Hi Maxim, Try switching to gdm and gnome, there have been some reports of problems with kdm and certain video cards. boot like; gentoo-nofb nox # go ahead and set root pw and reset user gentoo pw passwd passwd gentoo # set as gentoo (this may not be needed) # edit /etc/conf.d/xdm s/kdm/gdm # start gdm /etc/init.d/xdm start any better? -- David Abbott (dabbott)
[gentoo-user] fbpanell alternatives
Hi, since fbpanel is not themeable as far as I know and my eyes have problems to clearly recgonize the red numbers of the desktops numeration and the current-desktop cursor I am looking for another light panel to uses in conjunction with openbox. What panel with a similiar functionality can be suggested? The colors should be tuneable. Thank you very much for any help in advance! Have a nice weekend! Best regards mcc -- Please don't send me any Word- or Powerpoint-Attachments unless it's absolutely neccessary. - Send simply Text. See http://www.gnu.org/philosophy/no-word-attachments.html In a world without fences and walls nobody needs gates and windows.
Re: [gentoo-user] sys-libs/db-4.7.25_p4 fetch failure
On 17 Oct 2009, at 21:10, Dale wrote: ... a) not use pastebin, but post the messages in your email? Unless they are seriously HUGE? Attach them as plain text or gzipped. If they are too HUGE for that then you're prolly doing something wrong. Screenshots should, IMO, be hosted somewhere rather than attached. Stroller.
Re: [gentoo-user] [OT Xfce4/KDE] A URL aware applet
=== On Sat, 10/17, Harry Putnam wrote: === I wondered if there is anything like that for Xfce and if anyone knows what that applet it? === I don't use that applet, and I think I would find that annoying. Here's what I do. I have a shell script: = 276 !$ cat ~/bin/urlhelper #!/bin/bash SEL=$(xclip -o -selection primary) if [ $? == 0 ] ; then xdg-open $SEL fi (be sure to emerge xclip) Bound to a hot-key using the xfce4 keyboard configuration to Super-g (for GO). Then, whenever I know I have some url selected (I don't need an applet to tell me) I just have to press the key combination and off it goes. :-) -- Keith Dart -- -- Keith Dart ke...@dartworks.biz ===
Re: [gentoo-user] OT: Openmoko Freerunner as USB client
On 18 Oct 2009, at 00:09, Alex Schuster wrote: ... The hack that springs to mind is to see if you can pick up an Openmoko Freerunner with a broken screen. I'd guess you might be able to pick one up for as little as $50 or so. It needs no SIM - you just connect it to your office wifi instead, configure it to act as a mass storage device and share the appropriate directory by Samba or NFS or whatever. ... Well, even $200 might be okay. I need this for a commercial project anyway, and I guess the customer would be happy not to have to move around USB sticks. Honestly, I'm a little staggered the supplier of the ultrasound PC doesn't offer a network share. I mean, you can lock things down and still offer a network share; if USB memory sticks are permitted then there is room to accommodate this. But even better, I guess already have such a thing! My girl-friend got one a year ago, but was not happy with it. I just uses too much energy, has to be recharged every day. And there is some bug, when the battery is completely dead, it cannot be recharged - the moko needs another battery to start, then it can be exchanged with the dead one and recharged. I believe that it was discovered you can start off USB power if you hold down the AUX button at the same time as the main power. I believe this works for 99% of Freerunners, so you remove the battery and test switching it on this way, connected to USB. If it works you don't need to worry about carrying a spare battery. Maybe there is s newer software, she hasn't looked for that for a while. And I thought the project is about dead anyway, but that may also be completely wrong. Anyway, the device would be already here, so I can play around with it. The SHR software seems to be pretty good, I get the impression that it has made vast improvements over the last year. I have to admit I really haven't used mine much, either, but this is for unrelated reasons of disorganisation and laziness. I would say that, yes, hardware development seems to be pretty much dead (although they are still manufacturing the units new), but actually the community and software projects are really active. I tried the SHR unstable (it's more stable than the stable) and it seems pretty useable. I think it'll maybe be great if it continues to improve at this rate. I think what has really killed Openmoko is the inability to get hold of 3G chips in the low quantities and licensing terms they required. Lack of camera and 3G were the biggest source of this is lame, i was really interested but lacking these i'm not buying a freerunner whinges on the mailing list. I think now, a year or so later, and looking to the future this looks really dated. I gather Openmoko have pretty dropped development of phones, although this WikiReder was announced last week, and apparently something else is in the pipeline. I would be quite interested if the SHR platform was ported to run on Android hardware - I don't see anything else with the Freerunner's screen resolution, but aside from that all the Android phones have 3G, cameras (not that I care about that) and a decent form-factor. I prefer the notion of being able to code in whatever language I want, even though I'm (realistically speaking) unlikely to get my ass in gear and actually do any, rather than being tied down to some whacky Java-esque environment. I started tinkering with my Freerunner again recently, installed SHR unstable, and it was really nice being able to install from an OSS repository using the command-line. Stroller.
