Re: [gentoo-user] Re: Xorg 1.9.2 and wrong display size
On Monday 03 January 2011 01:21:46 fe...@crowfix.com wrote: On Mon, Jan 03, 2011 at 12:33:18AM +, Mick wrote: On Sunday 02 January 2011 21:18:14 fe...@crowfix.com wrote: On Sun, Jan 02, 2011 at 01:07:40PM -0800, walt wrote: On 01/02/2011 11:25 AM, fe...@crowfix.com wrote: My 1.9.2 upgrade didn't lose the keys, but it thinks the screen has fewer pixels than before, and what it does use is pushed off to the right (there is a column down the left side, roughly 10-20% of the screen, which is inaccessible). I've included 3 logs -- the working 1.8.2, the failing 1.9.2, and the failing /var/log/Xorg.0.log... The 'failing' log shows that the new Xorg-server is using the MACH64 driver, but your 'working' 1.8.2 log is truncated, so it doesn't tell us which video driver it was using successfully. I'm about 99% certain that it has always used the mach64 driver. I wish I had an old enough backup to recover an old log, but this current size screwup has been in effect for a while. It's mostly a server, so X isn't vital, but I do want to get it working again. Given only 8MB of video memory, maybe the vesa driver would work better? Dunno. Does your BIOS have a setting for the video aperture? You may get better results if you enable KMS in your kernel. Hmmm ... I hadn't remembered KMS until I googled it, so I tried this ... # grep KMS /usr/src/linux/.config CONFIG_DRM_KMS_HELPER=m CONFIG_DRM_RADEON_KMS=y # CONFIG_DRM_I915_KMS is not set Is that good enough? I gather I915 is the Intel graphics. I modprobe'd drm_kms_helper and the resultant Xorg log was exactly the same except for one date/time stamp and all those [nn.nnn] times at the beginning of each line. I bit of googling found several old web pages, but they seemed somehow not very useful. One said I have to disable the framebuffers, not because they are dangerous, but because they don't support KMS. Since X unloads the framebuffer module, I won't worry about that. KMS won't work with framebuffer modules like vesa/uvesa/radeonfb/etc. unless you also add nomodeset at the kernel line in GRUB. Instead of me repeating it all, I suggest you have look at: http://www.gentoo.org/doc/en/xorg-config.xm (but ignore what it says about HAL and its .fdi configuration files, because it is out of date with xorg-server-1.9.2) and also read: http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.8-upgrade-guide.xml -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: nvidia update problems
On Sunday 02 January 2011 15:51:24 walt wrote: On 01/02/2011 03:51 AM, Peter Humphrey wrote: It looks as though the boot sequence is going wrong somehow, because when I get my initial blank screen, if I then switch to a VT and restart xdm, everything works as expected. Just for clarification, are you saying that you can do that even without re-emerging nvidia-drivers? Exactly so - without doing anything other than restarting KDM. This is an ~amd64 box, by the way. So, when you first switch to the VT, the nvidia module is already loaded? Yes; without it I wouldn't see a blinking cursor. I think the raster would be absent too if nothing were driving the hardware. The boot sequence is complete. Is there an X session already running before you restart kdm? (I don't use any of *dm, so I don't know if they are X apps that require X to be running before they can write to the screen.) As far as I know, KDM starts X itself. At VT4 (which I use habitually for root logins) I issue the command: $ /etc/init.d/xdm restart logout which starts the KDM session as normal. -- Rgds Peter. Linux Counter 5290, 1994-04-23.
Re: [gentoo-user] How 2 disable synaptic pad (driver)
On Monday 03 January 2011 07:57:10 x...@synapse.plus.com wrote: On Mon, 03 Jan 2011, James wrote: Hello, so I got xorg-server working just fine on several machines...(*!/#FFF) Now I want to disable the synaptic pad on a laptop. The first laptop I want to do this to is working without any xorg.conf file nor a /etc/X11/xorg.conf.d/ dir. This chipset is a RADEON XPRESS 20M (5955) So is this file the best one to try to disable the synaptic driver? /etc/X11/xorg.conf.d/10-evdev.conf Suggestions are most welcome as googling has not produced much, related to xorg-server-1.9.2 and how to disable the synaptic pad (driver). James hi james, i know of 2 methods - either using synclient or xinput. if the synclient method doesn't work, simply install xinput and the latter one should work. cat ~/bin/toggle-touchpad #/bin/sh # synclient version if(synclient -l | grep TouchpadOff | grep -q 0) ; then synclient TouchpadOff=1 else synclient TouchpadOff=0 fi cat ~/bin/toggle-touchpad #/bin/sh # xinput version if(xinput list-props TouchPad | grep Synaptics Off | grep -q 0) ; then xinput set-int-prop TouchPad Synaptics Off 8 1 else xinput set-int-prop TouchPad Synaptics Off 8 0 fi Or if you want to use the xorg configuration files you can try creating: /etc/X11/xorg.conf.d/10-evdev.conf and adding the option: Option TouchpadOff 1 under the synaptics class, or set it to 2 if you want only tapping scrolling switched off. If this does not work (as was the case here) then you can instead modify /usr/share/X11/xorg.conf.d/10-evdev.conf (but will be overwritten when you remerge/update evdev). If this still does not work sigh... then evdev will not do it - you need instead the synaptics driver to load and capture the events from your touchpad. I assume that this may be a rare case, but since I came across it this is what you need to try: Add Option AllowEmptyInput off in your Section ServerLayout of /etc/X11/xorg.conf. Then modify /etc/X11/xorg.conf.d/50-synaptics.conf or /usr/share/X11/xorg.conf.d/50-synaptics.conf and add Option TouchpadOff 1 in there. Theoretically, files in /etc/X11/xorg.conf.d/ should take precedence over files in /usr/share/X11/xorg.conf.d/, but practically this is not always the case. HTH -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: nvidia update problems
On 01/03/2011 02:11 AM, Peter Humphrey wrote: On Sunday 02 January 2011 15:51:24 walt wrote: On 01/02/2011 03:51 AM, Peter Humphrey wrote: It looks as though the boot sequence is going wrong somehow, because when I get my initial blank screen, if I then switch to a VT and restart xdm, everything works as expected. Just for clarification, are you saying that you can do that even without re-emerging nvidia-drivers? Exactly so - without doing anything other than restarting KDM. This is an ~amd64 box, by the way. So nvidia.ko is not the problem then.(Unless it's being loaded too late in the boot sequence.) Is there an X session already running before you restart kdm? (I don't use any of *dm, so I don't know if they are X apps that require X to be running before they can write to the screen.) As far as I know, KDM starts X itself. At VT4 (which I use habitually for root logins) I issue the command: $ /etc/init.d/xdm restart logout which starts the KDM session as normal. I'm wondering if you have some mixture of baselayout versions on that machine from previous updates. A glance through the many relevant files in /etc/env.d/, /etc/conf.d/, /etc/X11*, /etc/rc.conf, /etc/init.d leaves me confused about what happens during xdm startup. Could your machine be trying to start something other than kdm by mistake? I.e., maybe you are starting kdm for the first time from the VT instead of re-starting it? I'd try touch /etc/.noxdm and reboot, then log in and do /etc/init.d/xdm start again. If that also works perfectly then I'd guess there is something in the list of directories above that is mis-configured -- my guess would be that the bootscripts are trying to start the wrong xdm -- just a SWAG :)
Re: [gentoo-user] Re: UPS driver error
On Sunday 02 January 2011 09:42:29 Francesco Talamona wrote:
I think is an issue with the UDEV rules.
At the end of /etc/udev/rules.d/10-local.rules I put this line for my
liebert USB UPS:
SUBSYSTEMS==usb,ATTRS{idVendor}==10af,ATTRS{idProduct}==0004,SYMLINK+
=liebert- ups MODE=0660, GROUP=nut, OPTIONS=last_rule
and in
/etc/nut/ups.conf
user = nut
[liebert]
port = /dev/liebert-ups
driver = liebert
Make sure also about permissions:
lrwxrwxrwx 1 root root 11 2 gen 10.34 /dev/liebert-ups - usb/hiddev0
crw-rw 1 root nut 180, 96 2 gen 10.34 usb/hiddev0
Thanks Francesco, I have now added the symlink to see if it makes a
difference, however, as I was poking around I noticed that there is *no*
hiddev* device at all ... is this an indication that something is amiss with
my kernel?
# cat /usr/src/linux/.config | grep -i hid
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
CONFIG_HIDRAW=y
CONFIG_USB_HID=y
# CONFIG_HID_PID is not set
CONFIG_USB_HIDDEV=y
# Special HID drivers
# CONFIG_HID_3M_PCT is not set
CONFIG_HID_A4TECH=y
# CONFIG_HID_ACRUX_FF is not set
CONFIG_HID_APPLE=y
CONFIG_HID_BELKIN=y
# CONFIG_HID_CANDO is not set
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
# CONFIG_HID_PRODIKEYS is not set
CONFIG_HID_CYPRESS=y
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EGALAX is not set
CONFIG_HID_EZKEY=y
CONFIG_HID_KYE=y
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_TWINHAN is not set
CONFIG_HID_KENSINGTON=y
CONFIG_HID_LOGITECH=y
CONFIG_HID_MICROSOFT=y
# CONFIG_HID_MOSART is not set
CONFIG_HID_MONTEREY=y
# CONFIG_HID_NTRIG is not set
# CONFIG_HID_ORTEK is not set
# CONFIG_HID_PANTHERLORD is not set
# CONFIG_HID_PETALYNX is not set
# CONFIG_HID_PICOLCD is not set
# CONFIG_HID_QUANTA is not set
# CONFIG_HID_ROCCAT is not set
# CONFIG_HID_ROCCAT_KONE is not set
# CONFIG_HID_SAMSUNG is not set
# CONFIG_HID_SONY is not set
# CONFIG_HID_STANTUM is not set
# CONFIG_HID_SUNPLUS is not set
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TOPSEED is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_ZEROPLUS is not set
# CONFIG_HID_ZYDACRON is not set
Anyway, with the modified rule in /etc/udev/rules.d/70-nut-usbups.rules:
ATTR{idVendor}==075d, ATTR{idProduct}==0300, SYMLINK+=iDowell,
MODE=664, GROUP=nut
I still get the same errors.
The symlink itself is not associated with hiddev*, but as follows:
ls -la /dev/iDowell
lrwxrwxrwx 1 root root 15 Jan 3 15:12 /dev/iDowell - bus/usb/003/056
Of course, since the device seems to be disconnected and reconnected
continuously, the link similarly changes the device file that it points to. A
few seconds later I get:
ls -la /dev/iDowell
ls: cannot access /dev/iDowell: No such file or directory
and then soon after:
ls -la /dev/iDowell
lrwxrwxrwx 1 root root 15 Jan 3 15:14 /dev/iDowell - bus/usb/003/063
Any ideas what I should be looking for, or what driver might work with this
baby?
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] SVGA mode the console
On Sun, Jan 2, 2011 at 5:28 AM, meino.cra...@gmx.de wrote: Final question after all there words: How can I get such a high resolution with this hardware and the nvidia-drivers??? http://dev.gentoo.org/~spock/projects/uvesafb/ Works for me on ~amd64 gentoo with nvidia-drivers :)
[gentoo-user] Re: How 2 disable synaptic pad (driver)
Mick michaelkintzios at gmail.com writes: Now I want to disable the synaptic pad on a laptop. Or if you want to use the xorg configuration files you can try creating: /etc/X11/xorg.conf.d/10-evdev.conf and adding the option: Option TouchpadOff 1 FANTASTIC! Section InputClass Identifier touchpad catchall MatchIsTouchpad on MatchDevicePath /dev/input/event* Option TouchpadOff 1 Driver synaptics Works like a charm! thx Mick, James
Re: [gentoo-user] Re: Xorg 1.9.2 and wrong display size
On Mon, Jan 03, 2011 at 09:37:23AM +, Mick wrote: KMS won't work with framebuffer modules like vesa/uvesa/radeonfb/etc. unless you also add nomodeset at the kernel line in GRUB. I'm not using those modules. Unless KMS actively breaks because those modules exist but aren't loaded, I don't see how framebuffer modules are the problem. http://www.gentoo.org/doc/en/xorg-config.xm I added VIDEO_CARDS and remerged xorg-server and xorg-drivers. This made no difference; the log file is exactly the same other than a minor Mhz change. http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.8-upgrade-guide.xml It tells how to set up a config file for 1.8, which I had working without a config file, so this particular upgrade guide seems rather useless. My only problem is that 1.9.2 doesn't set the right screen size. That probably does point to KMS in some manner, but a 1.8 upgrade guide doesn't deal with it. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman rocket surgeon / fe...@crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o
Re: [gentoo-user] Re: How 2 disable synaptic pad (driver)
On Monday 03 January 2011 16:21:41 James wrote: Mick michaelkintzios at gmail.com writes: Now I want to disable the synaptic pad on a laptop. Or if you want to use the xorg configuration files you can try creating: /etc/X11/xorg.conf.d/10-evdev.conf and adding the option: Option TouchpadOff 1 FANTASTIC! Section InputClass Identifier touchpad catchall MatchIsTouchpad on MatchDevicePath /dev/input/event* Option TouchpadOff 1 Driver synaptics Works like a charm! thx Mick, James You're welcome! Glad it works for you, because over here I had to go back and forth to get things working (mind you I was trying to do achieve the opposite functionality to yours). -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Changing boot device with 2.6.36
Hi, starting with the 2.6.36-r5 kernel of the Gentoo sources my boot device changes. With 2.6.35 and below it is alway /dev/sda3, with the new kernel it seems that anything that is internally connected with USB is assigned a device first. Since my computer has an internal media bay (and my monitor has such a thing also) the first HD moves - it I take care it is now /dev/sde3. However, if I forget to switch on the monitor and do this later or if an USB stick is already plugged in at boot time, the HD gets a different device number again. Can somebody else confirm such a behaviour with the 2.6.36 kernel and how can this brought back to normal operation? - Jörg
Re: [gentoo-user] SVGA mode the console
Paul Hartman paul.hartman+gen...@gmail.com [11-01-03 17:27]: On Sun, Jan 2, 2011 at 5:28 AM, meino.cra...@gmx.de wrote: Final question after all there words: How can I get such a high resolution with this hardware and the nvidia-drivers??? http://dev.gentoo.org/~spock/projects/uvesafb/ Works for me on ~amd64 gentoo with nvidia-drivers :) Hi, that sounds really promising! :) I tried to compile the stuff...but... When starting to emerge v86d (was it that name...cant remember exactly) also linux-2.6.26 starts to download and klibc.* I checked, for what klibc is good for and in this case it is used for calling the userland tool via from initram, which I do not plan... Ok, I thought, than low level. I compiled v86d by hand using ./configure --default for the default configuration. But this time it fails to compile with: make[1]: Leaving directory `/home/mccramer/data/downloads/v86d-0.1.9/libs/x86emu' cc -march=native -O2 -pipe -msse3 -I/lib/modules/2.6.36.2/source/include -Ilibs/x86emu -c -o v86_x86emu.o v86_x86emu.c In file included from /usr/include/asm/types.h:4, from /lib/modules/2.6.36.2/source/include/linux/types.h:4, from /lib/modules/2.6.36.2/source/include/linux/connector.h:25, from v86.h:7, from v86_x86emu.c:4: /lib/modules/2.6.36.2/source/include/asm-generic/int-ll64.h:11:29: error: asm/bitsperlong.h: No such file or directory In file included from /lib/modules/2.6.36.2/source/include/linux/connector.h:25, from v86.h:7, from v86_x86emu.c:4: /lib/modules/2.6.36.2/source/include/linux/types.h:13:2: warning: #warning Attempt to use kernel headers from user space, see http://kernelnewbies.org/KernelHeaders; make: *** [v86_x86emu.o] Error 1 I dont know, what the problem is...I am using linux-2.6.36.2 vanilla and compile this kernel with uvesafb support in beforehand. Nonetheless there seems something to be missed in the kernel sources... My goal is to have a better resolution on the console as this 8bit homecomputer like crap. It doesnot matter that much, whether switching to the higher resolution happens when the first boot scripts are read from /etc ... May I ask you for a little more informations how to proceed here? How did you achieve a working uvesafb? Do you use the gentoo sources or the vanilla kernel? Best regards and thank you very much in advance for your help! mcc
Re: [gentoo-user] SVGA mode the console
Paul Hartman paul.hartman+gen...@gmail.com [11-01-03 17:27]: On Sun, Jan 2, 2011 at 5:28 AM, meino.cra...@gmx.de wrote: Final question after all there words: How can I get such a high resolution with this hardware and the nvidia-drivers??? http://dev.gentoo.org/~spock/projects/uvesafb/ Works for me on ~amd64 gentoo with nvidia-drivers :) Ok, forget the previous mail... ;) I give up not to use initramfs and did it as described in above webpage. Unfortunately I get an even more blocky design (4bit pocket calculator design, so to say... ;-/ ) Will try more...we will see. If you have some more hints forI would be happier ;))) Best regards mcc
Re: [gentoo-user] Re: Xorg 1.9.2 and wrong display size
fe...@crowfix.com wrote: On Mon, Jan 03, 2011 at 09:37:23AM +, Mick wrote: KMS won't work with framebuffer modules like vesa/uvesa/radeonfb/etc. unless you also add nomodeset at the kernel line in GRUB. I'm not using those modules. Unless KMS actively breaks because those modules exist but aren't loaded, I don't see how framebuffer modules are the problem. http://www.gentoo.org/doc/en/xorg-config.xm I added VIDEO_CARDS and remerged xorg-server and xorg-drivers. This made no difference; the log file is exactly the same other than a minor Mhz change. http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.8-upgrade-guide.xml It tells how to set up a config file for 1.8, which I had working without a config file, so this particular upgrade guide seems rather useless. My only problem is that 1.9.2 doesn't set the right screen size. That probably does point to KMS in some manner, but a 1.8 upgrade guide doesn't deal with it. I ran into a weird video issue a month or so ago and there was a lot of head scratching. Just out of curiosity, do you have this built into the kernel under 'General Setup? System V IPC Again, I have that built in the kernel not as a module. It fixed my problem and I hope it will help on yours to. Dale :-) :-)
[gentoo-user] Re: Changing boot device with 2.6.36
On 01/03/2011 07:43 PM, Jörg Schaible wrote: Hi, starting with the 2.6.36-r5 kernel of the Gentoo sources my boot device changes. With 2.6.35 and below it is alway /dev/sda3, with the new kernel it seems that anything that is internally connected with USB is assigned a device first. Since my computer has an internal media bay (and my monitor has such a thing also) the first HD moves - it I take care it is now /dev/sde3. However, if I forget to switch on the monitor and do this later or if an USB stick is already plugged in at boot time, the HD gets a different device number again. Can somebody else confirm such a behaviour with the 2.6.36 kernel and how can this brought back to normal operation? This has been solved long ago: Label your filesystems and mount them by label. For example, don't put /dev/sda3 in your fstab, but label that filesystem with a name like root_fs and use /dev/disk/by-label/root_fs in fstab. Ext2/3/4 filesystem can be labeled with the e2label tool. For example: e2label /dev/sda3 root_fs After that, modify your fstab accordingly.
Re: [gentoo-user] Changing boot device with 2.6.36
On Mon, Jan 3, 2011 at 9:43 AM, Jörg Schaible joerg.schai...@gmx.de wrote: Hi, starting with the 2.6.36-r5 kernel of the Gentoo sources my boot device changes. With 2.6.35 and below it is alway /dev/sda3, with the new kernel it seems that anything that is internally connected with USB is assigned a device first. Since my computer has an internal media bay (and my monitor has such a thing also) the first HD moves - it I take care it is now /dev/sde3. However, if I forget to switch on the monitor and do this later or if an USB stick is already plugged in at boot time, the HD gets a different device number again. Can somebody else confirm such a behaviour with the 2.6.36 kernel and how can this brought back to normal operation? - Jörg Hello Jorg, I saw something similar recently going to the first version of 2.6.36. In my case I had a USB device externally connected through a specific USB hub. When I got rid of the hub and plugged the drive in directly it started booting correctly again. I don't see this with 2,6,36 with Flash drives plugged in but none of mine are bootable. I never investigated the root cause of why it was happening but I suspect it's some USB kernel setting. Strangeness. - Mark
Re: [gentoo-user] Re: Xorg 1.9.2 and wrong display size
On Monday 03 January 2011 17:12:11 fe...@crowfix.com wrote: On Mon, Jan 03, 2011 at 09:37:23AM +, Mick wrote: KMS won't work with framebuffer modules like vesa/uvesa/radeonfb/etc. unless you also add nomodeset at the kernel line in GRUB. I'm not using those modules. Unless KMS actively breaks because those modules exist but aren't loaded, I don't see how framebuffer modules are the problem. http://www.gentoo.org/doc/en/xorg-config.xm I don't know because on my boxen I had the framebuffer modules built in the kernel. Therefore I had to recompile the kernel with all the KMS settings as suggested in the article above and remove the framebuffer modules completely. I added VIDEO_CARDS and remerged xorg-server and xorg-drivers. This made no difference; the log file is exactly the same other than a minor Mhz change. http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.8-upgrade-guide .xml It tells how to set up a config file for 1.8, which I had working without a config file, so this particular upgrade guide seems rather useless. My only problem is that 1.9.2 doesn't set the right screen size. That probably does point to KMS in some manner, but a 1.8 upgrade guide doesn't deal with it. I think that the solution is probably to go for the full KMS approach and remove the framebuffer modules as already suggested. Then come back if it doesn't work. The xorg-server-1.8 migration is necessary if you need to configure particular devices. HAL and its fdi files are no longer used. In absence of any other configuration files under /etc/X11/*, xorg will use the files in /usr/share/X11/xorg.conf.d/* which may or may not agree with your hardware. That's what the xorg-server-1.8 migration URL is for. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Xorg 1.9.2 and wrong display size
On Mon, Jan 03, 2011 at 12:12:41PM -0600, Dale wrote: I ran into a weird video issue a month or so ago and there was a lot of head scratching. Just out of curiosity, do you have this built into the kernel under 'General Setup? System V IPC Again, I have that built in the kernel not as a module. It fixed my problem and I hope it will help on yours to. I just checked, yes, builtin, not a module. One of the most annoying gentoo habits I have developed is learning to live with things that break for no apparent reason and fix themselves for no apparent reason some time later, whether days or weeks. This one has been a problem for months now, but since I reboot as seldom as possible, and leave X running for weeks or months at a time, I don't know how long it has been broken. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman rocket surgeon / fe...@crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o
Re: [gentoo-user] Re: Xorg 1.9.2 and wrong display size
On Mon, Jan 03, 2011 at 06:53:05PM +, Mick wrote: I don't know because on my boxen I had the framebuffer modules built in the kernel. Therefore I had to recompile the kernel with all the KMS settings as suggested in the article above and remove the framebuffer modules completely. ... I think that the solution is probably to go for the full KMS approach and remove the framebuffer modules as already suggested. Then come back if it doesn't work. I just tried this; no change to either the Xorg.log or the screen size. The xorg-server-1.8 migration is necessary if you need to configure particular devices. HAL and its fdi files are no longer used. In absence of any other configuration files under /etc/X11/*, xorg will use the files in /usr/share/X11/xorg.conf.d/* which may or may not agree with your hardware. That's what the xorg-server-1.8 migration URL is for. The only files in there are for evdev and the mouse. Input works fine, both keyboard and mouse. Well, it will probably resolve itself one of these days, like so many other gentoo screwups. I've had LVM issues, USB issues by the ton, I have forgotten most of the problems; they seem to eventually fix themselves. It's as if projects get out of sync, leapfrogging each other, and I happen to hit them at some particularly bad leapfrog and it takes a while for them to get back together. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman rocket surgeon / fe...@crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o
[gentoo-user] Re: Changing boot device with 2.6.36
Nikos Chantziaras wrote: On 01/03/2011 07:43 PM, Jörg Schaible wrote: Hi, starting with the 2.6.36-r5 kernel of the Gentoo sources my boot device changes. With 2.6.35 and below it is alway /dev/sda3, with the new kernel it seems that anything that is internally connected with USB is assigned a device first. Since my computer has an internal media bay (and my monitor has such a thing also) the first HD moves - it I take care it is now /dev/sde3. However, if I forget to switch on the monitor and do this later or if an USB stick is already plugged in at boot time, the HD gets a different device number again. Can somebody else confirm such a behaviour with the 2.6.36 kernel and how can this brought back to normal operation? This has been solved long ago: Label your filesystems and mount them by label. I did this long ago, therefore I can switch between the old and new kernel easily. For example, don't put /dev/sda3 in your fstab, but label that filesystem with a name like root_fs and use /dev/disk/by-label/root_fs in fstab. Ext2/3/4 filesystem can be labeled with the e2label tool. For example: e2label /dev/sda3 root_fs After that, modify your fstab accordingly. And how does this help the kernel to find the root device where /etc/fstab is located ? - Jörg BTW: Yes, I will boot next time with a LABEL entry in the kernels boot option, but I still don't want a kernel that assigns devices in random order.
Re: [gentoo-user] SVGA mode the console
On Mon, Jan 3, 2011 at 11:55 AM, meino.cra...@gmx.de wrote: Paul Hartman paul.hartman+gen...@gmail.com [11-01-03 17:27]: On Sun, Jan 2, 2011 at 5:28 AM, meino.cra...@gmx.de wrote: Final question after all there words: How can I get such a high resolution with this hardware and the nvidia-drivers??? http://dev.gentoo.org/~spock/projects/uvesafb/ Works for me on ~amd64 gentoo with nvidia-drivers :) Hi, that sounds really promising! :) I tried to compile the stuff...but... When starting to emerge v86d (was it that name...cant remember exactly) also linux-2.6.26 starts to download and klibc.* I checked, for what klibc is good for and in this case it is used for calling the userland tool via from initram, which I do not plan... Ok, I thought, than low level. I compiled v86d by hand using ./configure --default for the default configuration. But this time it fails to compile with: make[1]: Leaving directory `/home/mccramer/data/downloads/v86d-0.1.9/libs/x86emu' cc -march=native -O2 -pipe -msse3 -I/lib/modules/2.6.36.2/source/include -Ilibs/x86emu -c -o v86_x86emu.o v86_x86emu.c In file included from /usr/include/asm/types.h:4, from /lib/modules/2.6.36.2/source/include/linux/types.h:4, from /lib/modules/2.6.36.2/source/include/linux/connector.h:25, from v86.h:7, from v86_x86emu.c:4: /lib/modules/2.6.36.2/source/include/asm-generic/int-ll64.h:11:29: error: asm/bitsperlong.h: No such file or directory In file included from /lib/modules/2.6.36.2/source/include/linux/connector.h:25, from v86.h:7, from v86_x86emu.c:4: /lib/modules/2.6.36.2/source/include/linux/types.h:13:2: warning: #warning Attempt to use kernel headers from user space, see http://kernelnewbies.org/KernelHeaders; make: *** [v86_x86emu.o] Error 1 I dont know, what the problem is...I am using linux-2.6.36.2 vanilla and compile this kernel with uvesafb support in beforehand. Nonetheless there seems something to be missed in the kernel sources... My goal is to have a better resolution on the console as this 8bit homecomputer like crap. It doesnot matter that much, whether switching to the higher resolution happens when the first boot scripts are read from /etc ... May I ask you for a little more informations how to proceed here? How did you achieve a working uvesafb? Do you use the gentoo sources or the vanilla kernel? Hi, I use vanilla-sources and do not use initrd. Don't be confused about initramfs, it does not require you to use initrd. Basically just follow the directions on that webpage and it should work. Here I'll explain in different words in case it helps. :) 1. configure your kernel like it says on that page (CONFIG_CONNECTOR=y and CONFIG_FB_UVESA=y) 2. make the kernel 3. emerge klibc (if it's already installed, emerge it again so it builds against this newly-configured kernel) 4. emerge v86d 5. configure your kernel again, enable Initial RAM filesystem and RAM disk (initramfs/initrd) support 6. In Initramfs source file(s) type /usr/share/v86d/initramfs 7. Make and install the new kernel :) 8. Reboot and type cat /sys/class/graphics/fb0/modes to see a list of compatible modes on your card. 9. Edit your kernel commandline in grub configuration file to add the uvesafb command. For example mine is video=uvesafb:1280x720p-59,mtrr:2,ywrap (you can replace 1280x720p-59 with the mode that your card supports from the previous step) 9. Reboot again and hopefully enjoy new high-resolution framebuffer :) Another way to make it look better is to use different console fonts. I'm using ter-112n from package media-fonts/terminus-font. You can set this in /etc/conf.d/consolefont (be sure consolefont is set as a boot service from rc-update). If you have a message in dmesg about mtrr type mismatch, you may need to change from mtrr:2 to another number. Please read the uvesafb documentation from linux kernel for more info: /usr/src/linux/Documentation/fb/uvesafb.txt Good luck :) If you have any problems let me know and I can send you my kernel .config in case you want to compare settings.
Re: [gentoo-user] Re: Changing boot device with 2.6.36
On 3/1/2011, at 6:17pm, Nikos Chantziaras wrote: On 01/03/2011 07:43 PM, Jörg Schaible wrote: ... starting with the 2.6.36-r5 kernel of the Gentoo sources my boot device changes. With 2.6.35 and below it is alway /dev/sda3, with the new kernel it seems that anything that is internally connected with USB is assigned a device first. ... This has been solved long ago: Label your filesystems and mount them by label. For example, don't put /dev/sda3 in your fstab, but label that filesystem with a name like root_fs and use /dev/disk/by-label/root_fs in fstab. Ext2/3/4 filesystem can be labeled with the e2label tool. For example: e2label /dev/sda3 root_fs After that, modify your fstab accordingly. I believe this is the supported way to use labels: $ grep -v -e ^# -e ^$ /etc/fstab LABEL=boot /boot ext2noauto,noatime 1 2 LABEL=/ / ext4noatime 0 1 LABEL=swap noneswapsw 0 0 /dev/cdrom /mnt/cdrom autonoauto,ro,users 0 0 LABEL=space /mnt/space ext4noatime 0 3 shm /dev/shmtmpfs nodev,nosuid,noexec 0 0 $ Stroller.
[gentoo-user] Re: SVGA mode the console
On 01/03/2011 08:09 PM, meino.cra...@gmx.de wrote: Paul Hartmanpaul.hartman+gen...@gmail.com [11-01-03 17:27]: On Sun, Jan 2, 2011 at 5:28 AM,meino.cra...@gmx.de wrote: Final question after all there words: How can I get such a high resolution with this hardware and the nvidia-drivers??? http://dev.gentoo.org/~spock/projects/uvesafb/ Works for me on ~amd64 gentoo with nvidia-drivers :) Ok, forget the previous mail... ;) I give up not to use initramfs and did it as described in above webpage. Unfortunately I get an even more blocky design (4bit pocket calculator design, so to say... ;-/ ) Will try more...we will see. If you have some more hints forI would be happier ;))) uvesafb will not give you extra resolutions. It will however allow you to use non-default refresh-rates which is sometimes useful with CRT monitors. But it has a drawback too: it needs a userspace tool and resolution is switched too late during the boot process, meaning until it loads you'll be seeing the kernel boot in 80x25 mode (which in turn means no boot graphics/logo right from the start.)
Re: [gentoo-user] Changing boot device with 2.6.36
On Mon, Jan 3, 2011 at 11:43 AM, Jörg Schaible joerg.schai...@gmx.de wrote: Hi, starting with the 2.6.36-r5 kernel of the Gentoo sources my boot device changes. With 2.6.35 and below it is alway /dev/sda3, with the new kernel it seems that anything that is internally connected with USB is assigned a device first. Since my computer has an internal media bay (and my monitor has such a thing also) the first HD moves - it I take care it is now /dev/sde3. However, if I forget to switch on the monitor and do this later or if an USB stick is already plugged in at boot time, the HD gets a different device number again. Can somebody else confirm such a behaviour with the 2.6.36 kernel and how can this brought back to normal operation? Is it possible that your BIOS is changing device order? Do you have USB device set to boot before HDD device?
Re: [gentoo-user] Re: SVGA mode the console
On Mon, Jan 3, 2011 at 2:07 PM, Nikos Chantziaras rea...@arcor.de wrote: uvesafb will not give you extra resolutions. It will however allow you to use non-default refresh-rates which is sometimes useful with CRT monitors. But it has a drawback too: it needs a userspace tool and resolution is switched too late during the boot process, meaning until it loads you'll be seeing the kernel boot in 80x25 mode (which in turn means no boot graphics/logo right from the start.) I use uvesafb and I can see Tux (eight of him) during my boot process before uvesafb kicks in.
Re: [gentoo-user] Re: Changing boot device with 2.6.36
Apparently, though unproven, at 21:36 on Monday 03 January 2011, Jörg Schaible did opine thusly: Nikos Chantziaras wrote: On 01/03/2011 07:43 PM, Jörg Schaible wrote: Hi, starting with the 2.6.36-r5 kernel of the Gentoo sources my boot device changes. With 2.6.35 and below it is alway /dev/sda3, with the new kernel it seems that anything that is internally connected with USB is assigned a device first. Since my computer has an internal media bay (and my monitor has such a thing also) the first HD moves - it I take care it is now /dev/sde3. However, if I forget to switch on the monitor and do this later or if an USB stick is already plugged in at boot time, the HD gets a different device number again. Can somebody else confirm such a behaviour with the 2.6.36 kernel and how can this brought back to normal operation? This has been solved long ago: Label your filesystems and mount them by label. I did this long ago, therefore I can switch between the old and new kernel easily. For example, don't put /dev/sda3 in your fstab, but label that filesystem with a name like root_fs and use /dev/disk/by-label/root_fs in fstab. Ext2/3/4 filesystem can be labeled with the e2label tool. For example: e2label /dev/sda3 root_fs After that, modify your fstab accordingly. And how does this help the kernel to find the root device where /etc/fstab is located ? Does boot=LABEL=boot_device_label in grub config work for you? -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: Changing boot device with 2.6.36
On 3/1/2011, at 7:36pm, Jörg Schaible wrote: ... And how does this help the kernel to find the root device where /etc/fstab is located ? The kernel doesn't. You leave that to GRUB. I'm not saying this helps solve your problem, I'm just sayin'. BTW: Yes, I will boot next time with a LABEL entry in the kernels boot option, but I still don't want a kernel that assigns devices in random order. As long as you can boot, you should seriously stop caring. If you're concerned about mounting USB sticks or memory cards then use udev rules to distinguish them. Regarding the booting, and having to change what's in your grub.conf, I'd assume this is a one-off change - you'll change grub.conf to point to the new /dev/sdX and that will require no maintenance in the forseeable future. GRUB can do labels, but it needs an initrd or initramfs, I think. Stroller.
Re: [gentoo-user] Re: Xorg 1.9.2 and wrong display size
fe...@crowfix.com wrote: On Mon, Jan 03, 2011 at 12:12:41PM -0600, Dale wrote: I ran into a weird video issue a month or so ago and there was a lot of head scratching. Just out of curiosity, do you have this built into the kernel under 'General Setup? System V IPC Again, I have that built in the kernel not as a module. It fixed my problem and I hope it will help on yours to. I just checked, yes, builtin, not a module. One of the most annoying gentoo habits I have developed is learning to live with things that break for no apparent reason and fix themselves for no apparent reason some time later, whether days or weeks. This one has been a problem for months now, but since I reboot as seldom as possible, and leave X running for weeks or months at a time, I don't know how long it has been broken. If no one else has any ideas, I would start a emerge -e world. Maybe something updated and a dependency needs to be recompiled but no one else knows which one it is. I have in the past done this and it work. I usually start a screen session so that I can check on it either in a console or in KDE. You can also test it to see if it works from time to time too. Just run etc-update or something to check for config updates before testing Maybe someone else will come up with something that will help. No clue here, at the moment anyway. Dale :-) :-)
Re: [gentoo-user] Re: Calendar applications
Take a look at osmo http://clayo.org/osmo/. Regards Hamilton
[gentoo-user] Re: SVGA mode the console
On 01/03/2011 10:23 PM, Paul Hartman wrote: On Mon, Jan 3, 2011 at 2:07 PM, Nikos Chantziarasrea...@arcor.de wrote: uvesafb will not give you extra resolutions. It will however allow you to use non-default refresh-rates which is sometimes useful with CRT monitors. But it has a drawback too: it needs a userspace tool and resolution is switched too late during the boot process, meaning until it loads you'll be seeing the kernel boot in 80x25 mode (which in turn means no boot graphics/logo right from the start.) I use uvesafb and I can see Tux (eight of him) during my boot process before uvesafb kicks in. I mean more something like this when I say boot logo: http://mjanusz.files.wordpress.com/2008/02/shot.png It's at least 10 years since I saw that default Tux boot thingy :-P But anyway, if uvesafb hasn't kicked in yet, what on earth is drawing that Tux?
[gentoo-user] Latest unstable ntp not generating ntp.drift file.
Hi, I been watching my clock here for a while. On my old rig, ntp kept the clock set very, very well. This rig seems to have issues. I tried the stable version of ntp and it just seems to keep resetting the time but not adjusting the drift file at all. I even adjusted manually once and my entry was better than the one it made. I then decided to try the latest unstable ntp to see if maybe it would work better. I emerged ntp, renamed the drift file and started the service. That was several hours ago and it has yet to even create the drift file. It also puts nothing in the log file except that it started and is using ports and the normal stuff. No syncing or anything like the older version. Also, I copied the ntp.conf file over from the old rig. I would think they would work pretty much the same. Same program, same config and hopefully same results. First version tried: net-misc/ntp-4.2.4_p7-r1 Current unstable version: net-misc/ntp-4.2.6_p2-r1 When I looked at the ntp website, it said it should sync much faster than the old one. Basically it is minutes instead of hours. So far this is not the case. Anybody else ran into this? Am I missing something that is different on a 64 bit rig? Thanks. Dale :-) :-)
Re: [gentoo-user] SVGA mode the console
Paul Hartman paul.hartman+gen...@gmail.com [11-01-03 17:27]: On Sun, Jan 2, 2011 at 5:28 AM, meino.cra...@gmx.de wrote: Final question after all there words: How can I get such a high resolution with this hardware and the nvidia-drivers??? http://dev.gentoo.org/~spock/projects/uvesafb/ Works for me on ~amd64 gentoo with nvidia-drivers :) Hi all, thank you very much for all the input ! And(TADA!).it works now! :) Very last question: Is there any way to test what font looks best without haveing to boot each time ? Best regards, mcc
Re: [gentoo-user] SVGA mode the console
Hi, You can try to modify the default font in /etc/conf.d/consolefont and restart /etc/init.d/consolefont to see if the new font look OK for you or not. The terminus-font looks OK for me. Hope this help Hung On 01/03/11 20:04, meino.cra...@gmx.de wrote: Paul Hartman paul.hartman+gen...@gmail.com [11-01-03 17:27]: On Sun, Jan 2, 2011 at 5:28 AM, meino.cra...@gmx.de wrote: Final question after all there words: How can I get such a high resolution with this hardware and the nvidia-drivers??? http://dev.gentoo.org/~spock/projects/uvesafb/ Works for me on ~amd64 gentoo with nvidia-drivers :) Hi all, thank you very much for all the input ! And(TADA!).it works now! :) Very last question: Is there any way to test what font looks best without haveing to boot each time ? Best regards, mcc
