> While this enabled the mouse (without HAL), it did nothing good about: > > a. The bogus keyboard scans.Everyone is talking about an xorg.conf The new X.org 7.4 upgrade hit me too: no keyboard & no mouse! Bummer. I found that if I simply added to /etc/rc.conf: hald_enable="YES" that things now work for me. Previously I never have had hald in my rc.conf. Hope this helps. Dan
Although the hald_enable in /etc/rc.conf worked, I noticed that a lot of other demons get running. I needed to add dbus_enable as well. That fix is too intrusive in my book. In any event Firefox is now broken and does not run at all. I backed out the /etc/rc.conf changes and generated an xorg.conf by calling Xorg -configure. I moved this to /etc/xorg.conf. Things were still broken until I added the recommended Option "AllowEmptyInput" "off" in the ServerLayout section of xorg.conf. Now I can use X again BUT... Firefox 3.0.5 is still broken. It has worked fine until this new Xorg. This 7.4 version of X.org is not ready for STABLE! Dan
On Wed, 2009-01-28 at 21:11 -0700, Dan Allen wrote:> Although the hald_enable in /etc/rc.conf worked, I noticed that a lot > of other demons get running. I needed to add dbus_enable as well. > That fix is too intrusive in my book. > > In any event Firefox is now broken and does not run at all. > > I backed out the /etc/rc.conf changes and generated an xorg.conf by > calling Xorg -configure. I moved this to /etc/xorg.conf. Things were > still broken until I added the recommended > > Option "AllowEmptyInput" "off" > > in the ServerLayout section of xorg.conf. > > Now I can use X again BUT... Firefox 3.0.5 is still broken. It has > worked fine until this new Xorg.Firefox not working is one of the symptoms of a botched upgrade. If you ldd firefox-bin you will likely find that it is linked to both libxcb.so.1 and libxcb.so.2. This is not good, ensure that everything that depends on libxcb has been rebuilt. robert.> This 7.4 version of X.org is not ready for STABLE! > > Dan > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090129/5741c0cf/attachment.pgp
,--- You/Dan (Wed, 28 Jan 2009 20:39:10 -0700) ----*
| > While this enabled the mouse (without HAL), it did nothing good about:
| >
| > a. The bogus keyboard scans.
You are quoting me and I need to clarify...
| Everyone is talking about an xorg.conf
| The new X.org 7.4 upgrade hit me too: no keyboard & no mouse! Bummer.
| I found that if I simply added to /etc/rc.conf:
| hald_enable="YES"
| that things now work for me.
| Previously I never have had hald in my rc.conf.
| Hope this helps.
`--------------------------------------------------*
My worst case is not HAL-related: I had the same behavior with or
without HAL, and the behaviour was, e.g.:
* I press the keys "TAB q w" over an `xev' window and see the
bogus
key scan codes -- nothing related to the pressed keys.
* In a moment the xev-monitoring xterm window shows a non-stopping
flow of events, even though I am not touching anything on the
computer.
* With some combination of a few key presses over the `xterm'
window, suddenly a long stream of `2's appears. Or `z'. Or
something else, unrelated to the keys I had pressed.
There has been nothing of this sort on my desktop, where I am typing
this message -- so, I think I know how to configure X :-).
On this desktop I am currently running this new X (installed it on
Sunday) -- first I ran it with HAL, then today I switched to the
HAL-less mode.
I did complain about the garbage in my windows -- and it got me, there
was so much of it: I switched to the HAL-less mode a few hours ago and
so far it seems I have less of it.
Another thing that I am certain about, is that in the HAL mode (I am
not yet sure about the behavior in my current HAL-less mode), there is
a dramatically higher mouse pointer captivity by some applications
(e.g. `opera') -- it sometimes takes (took?) about 10 seconds after
shifting a pointer into an xterm or Emacs to be able to produce any
keyboard input. I did notice these things with the old X, but on a
scale dramatically smaller.
,--- You/Dan (Wed, 28 Jan 2009 21:11:13 -0700) ----*
| This 7.4 version of X.org is not ready for STABLE!
`--------------------------------------------------*
I hate to say this, but the new X (as exists in the current FreeBSD
ports) sucks and gets in the way of work big time.
-- Alex -- alex-goncharov@comcast.net --
,--- You/Robert (Wed, 28 Jan 2009 23:16:11 -0500) ----* | > Now I can use X again BUT... Firefox 3.0.5 is still broken. It has =20 | > worked fine until this new Xorg. | | Firefox not working is one of the symptoms of a botched upgrade. If you | ldd firefox-bin you will likely find that it is linked to both | libxcb.so.1 and libxcb.so.2. This is not good, ensure that everything | that depends on libxcb has been rebuilt. FWIW, firefox3 works for me (just installed it on my desktop). -- Alex -- alex-goncharov@comcast.net --
Hi list, after upgrading to Xorg 7.4 from the FreebSD ports tree I've got my USB stack completely unusable. If Xorg is started (manually or via xdm) my USB printer and external HDD become unreachable (timeouts). It is not enough to kill Xorg to restore the USB functionality. FreeBSD has to be restarted. I use FreeBSD 7.1-STABLE (amd64) compiled from fresh sources. Any tips? Regards, Serguey.
On Fri Jan 30 11:53:16 PST 2009, Peter Jeremy wrote:>As a general note, this is the second time in a row that an X.org >upgrade broke X for a significant number of people. IMO, this >suggests that our approach to X.org upgrades needs significant changes >(see below). X11 is a critical component for anyone who is using >FreeBSD as a desktop and having upgrades fail or come with significant >POLA violations and regressions for significant numbers of people is >not acceptable.The problem isn't so much as a problem with xorg updates as it is with the overall port approach. Not having a stable versus current ports approach is probably the biggest cause of the problems seen here. The port freezes don't help either. In general when upgrading, you take your chances. If a port upgrade fails, you should fall back to what worked. Trying to partial rebuild ports versus rebuilding from scratch after a major update is just asking for problems. There probably needs to be a more incremental approach when upgrading major ports. For example, I updated my system a piece at a time over the last several months, and had no significant problems with the offical x11 upgrade as the changes were small. And last, many of the video drivers have little if any support. If you have something other then ati/intel/nivdia, you should expect problems. Input drivers are in a similar state.
On Sunday 01 February 2009 13:11:21 Alex Goncharov wrote:> On Sun, 1 Feb 2009 12:33:56 +0000 I wrote: > | That is not to say the new Xorg doesn't work. The only problems I've > | seen on Radeons needed a couple of options lines in xorg.conf due to > | the hald/dbus/xorg race and an fdi to make the keyboard layout match > | what I actually have rather than "us". Easily fixed for now and 7.4 > | brings some fixes to my systems that I have been awaiting for quite > | some time, most notably the horrendous XPress 200M chipset now works > | with DRI. > > Knowing about specific things now fixed for specific users is very > encouraging.I had better post to the lists exactly what I did, having thrown that encouraging word out: Ensure the files section doesn't contain anything like RGBPath if you've upgraded, then add Option "AllowEmptyInput" "False" and Option "AutoAddDevices" "False" to the server layout section in xorg.conf. Then create a file ${LOCALBASE}/etc/hal/fdi/policy/x11-input.fdi with the following contents: <?xml version="1.0" encoding="ISO-8859-1"?> <deviceinfo version="0.2"> <device> <match key="info.capabilities" contains="input.keyboard"> <merge key="input.xkb.layout" type="string">gb</merge> </match> </device> </deviceinfo> Restart hald etc. This cleared up all issues of not playing nice with moused, missing keyboards and quotemarks on my @ key ;o) Obviously, you'll want to replace "gb" with whatever layout you require from ${LOCALBASE}/share/X11/xkb/symbols/. Note I have not tried hotplugging a USB mouse on this configuration. That's to come on the laptop, which works fine with its trackpad (although middle and right clicks have been redefined to three and two finger taps respectively - it was the other way around) with the updated xf86-input-synaptics driver. Which brings me to another little niggle: <aside> Has anyone on list noticed that statically compiling a keymap in your kernel >7.0-RELEASE ends up with the US layout in single user mode regardless? This used to work, but now it doesn't, unless I've missed something in NOTES somewhere. </aside>> Thanks a lot!You're very welcome. Best regards, -- Matt Dawson MTD15-RIPE matt@chronos.org.uk
,--- You/Matthew (Sun, 1 Feb 2009 14:48:15 -0600) ----* | On Sat, Jan 31, 2009 at 04:25:21PM -0500 I heard the voice of | Alex Goncharov, and lo! it spake thus: | > Csup can only go forward -- or can it go back?) | | You can specify a date in a supfile since, like, ever. `-----------------------------------------------------* Yes, other people have already pointed this out and I just got the code as of 2009.01.23.12.00.00 -- four hours before the first submission of the new X. Now I just need to think through my next steps :-) Thank you! -- Alex -- alex-goncharov@comcast.net --
I've just upgraded to the latest xorg on my amd64 box 7.1-STABLE FreeBSD 7.1-STABLE #0: Fri Jan 16 07:33:20 PST 2009 I have a radeon graphics card, drm0: <ATI Radeon RV280 9250> on vgapci0 - had to add the option mentioned in UPDATING Section "ServerLayout" Option "AllowEmptyInput" "off" ... Things seem mostly running on my box, though there are many of these emacs Xlib: extension "Generic Event Extension" missing on display ":0.0". ... I now see that ssh into a remote host (solaris 10 sparc), running emacs there pops up a window, but then typing anything into the window kills it, with X protocol error: BadAlloc (insufficient resources for operation) on protocol request 149 (on the remote machine). xv works ok. This doesn't happen if the remote host is linux rh4... This didn't happen before the xorg upgrade. Seems to be some sort of incompatibility in X11. Any ideas? Sam Sirlin
Dan Allen wrote:>> While this enabled the mouse (without HAL), it did nothing good about: >> >> a. The bogus keyboard scans. > Everyone is talking about an xorg.conf > The new X.org 7.4 upgrade hit me too: no keyboard & no mouse! Bummer. > I found that if I simply added to /etc/rc.conf: > hald_enable="YES" > that things now work for me. > Previously I never have had hald in my rc.conf. > Hope this helps. > Dan > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >List, After finally getting everything rebuilt (2.5 days) for this upgrade I am now getting in my Xorg.0.log: (II) Loading /usr/local/lib/xorg/modules/extensions//vnc.so dlopen: /usr/local/lib/xorg/modules/extensions//vnc.so: Undefined symbol "NumCurrentSelections" (EE) Failed to load /usr/local/lib/xorg/modules/extensions//vnc.so (II) UnloadModule: "vnc" (EE) Failed to load module "vnc" (loader failed, 7) anyone know how to fix this? It was very convenient to be able to run vncviewer without first having to ssh in and start vncserver by hand. Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson)
On 2009-02-19 13:21, Stephen Clark wrote:> (II) Loading /usr/local/lib/xorg/modules/extensions//vnc.so > dlopen: /usr/local/lib/xorg/modules/extensions//vnc.so: Undefined symbol > "NumCurrentSelections"This is a VNC problem, it uses an old API which has been removed in newer X.org servers: http://cgit.freedesktop.org/xorg/xserver/commit/?id=34bf308a9e66f1a2f48630a15b1802afad50ec24 See also here (and for possible workarounds): https://bugs.launchpad.net/bugs/260815