Re: Xorg on ASRock i945GZ problem
On Mar 19, 2009 5:13pm, Evgeniy Sudyr eject.in...@gmail.com wrote: Hi, all I have problem with Xorg on -current. Card is supported (as I see) but X not startx :(. vesabios0 at mainbus0: version 3.0, Intel Corporation Intel(r) 82945G Chipset Family Graphics Controller vesabios0: VESA mode 0160: attributes vesabios0: VESA mode 0161: attributes vesabios0: VESA mode 0162: attributes vesabios0: VESA mode 0163: attributes vesabios0: VESA mode 0164: attributes vesabios0: VESA mode 0165: attributes vesabios0: VESA mode 0166: attributes vesabios0: VESA mode 0167: attributes vesabios0: VESA mode 0168: attributes vesabios0: VESA mode 013c: attributes 009b, 1920x1440 8bbp Packed pixel vesabios0: VESA mode 014d: attributes 009b, 1920x1440 16bbp Direct Color vesabios0: VESA mode 015c: attributes vesabios0: VESA mode 013a: attributes 009b, 1600x1200 8bbp Packed pixel vesabios0: VESA mode 014b: attributes 009b, 1600x1200 16bbp Direct Color vesabios0: VESA mode 015a: attributes 009b, 1600x1200 32bbp Direct Color vesabios0: VESA mode 0107: attributes 009b, 1280x1024 8bbp Packed pixel vesabios0: VESA mode 011a: attributes 009b, 1280x1024 16bbp Direct Color vesabios0: VESA mode 011b: attributes 009b, 1280x1024 32bbp Direct Color vesabios0: VESA mode 0105: attributes 009b, 1024x768 8bbp Packed pixel vesabios0: VESA mode 0117: attributes 009b, 1024x768 16bbp Direct Color vesabios0: VESA mode 0118: attributes 009b, 1024x768 32bbp Direct Color vesabios0: VESA mode 0112: attributes 009b, 640x480 32bbp Direct Color vesabios0: VESA mode 0114: attributes 009b, 800x600 16bbp Direct Color vesabios0: VESA mode 0115: attributes 009b, 800x600 32bbp Direct Color vesabios0: VESA mode 0101: attributes 009b, 640x480 8bbp Packed pixel vesabios0: VESA mode 0103: attributes 009b, 800x600 8bbp Packed pixel vesabios0: VESA mode 0111: attributes 009b, 640x480 16bbp Direct Color You're not running GENERIC, since I see vesabios active here. This is the problem. Try with a true GENERIC kernel.
Re: xterm and home-dir with automounter
On Jan 11, 2009 12:44pm, Rudi Ludwig rud...@gmx.de wrote:
Hello,
for flexibility I have configured my computer (OpenBSD 4.4; macppc)
with the home directory being auto mounted.
that is /etc/amd/amd.home reads:
#
* type:=link;fs:=/usr/home;sublink:=${key}
This works as desired. The programs use /home/ as
they should, the real data locates in /usr/home. Of course, useradd
becomes a two step process.
But, the only program that doesn't play nicely is xterm. Either from
within an xsession or when login in remotely via ssh the initial path
is always: /usr/home/ despite $PATH being /home/
That is, xterm initially reads: ibook:/usr/home/rudi$
instead of just: ibook:~$
Is this a configuration issue or a bug/feature of xterm?
xterm is innocent here. It is the shell running inside xterm that displays
the prompt.
Which shell are you using, how did you configure the prompt?
with ksh(1), using export PS1='\h:\w$ ' to define the prompt, I get the
correct result most of the time, even if /bin/pwd reports
/usr/home/matthieu.
Other shells may behave differently.
Re: openbsd-current strange keyboard behaviour
Did you guys fiddle with /etc/ttys or the way to start X? This looks like the know problem of X and the process on console fighting for input because they are sharing the same virtual terminal device. Normally there's no getty(8) process attached to ttyC4 so that X can attach to it (and xdm isi configured to use vt05 - which corresponds to ttyC4 since VT numbers in X start at 01). If you activate a getty(8) process on this VT too, X will not find a free one and attach to ttyC0 anyways causing problems if you have processes trying to get input from ttyC0.
Re: VESA 1280x800
On Oct 19, 2008 4:30am, Jairo Souto [EMAIL PROTECTED] wrote: I updated xenocara from cvs, added the line you sugested in nv_driver.c and rebuilt xenocara. Then I tried to run Xorg without any xorg.conf and it did not run any more. Xorg.0.log is attached. ok, that means that the 7000 M is not some simple G80 chipset variant. You'll have to wait until support for this chipset is added to the 'xf86-video-nv' driver by its maintainer. You may want to try to fill a bug report on bugzilla.freedesktop.org, under the 'xorg' product to request it. Regards,
