X applications are not working unless the cursor or mouse is moving??

I'm not sure if any of you guys have encountered this (weird) situation.

First of all, my laptop spec is Compaq Presario 2166ae (AMD Athlon XP-M 2400+, ATI Radeon Mobile U1). I installed FreeBSD 7.2-RELEASE from DVD; that is, I'm not upgrading and everything is supposed to be updated.

After installing all distributions and packages on the DVD, I copied /root/xorg.conf.new to /etc/X11/xorg.conf, and enabled hal and dbus by adding the following two lines in /etc/rc.conf:

Code:
hald_enable="YES"
dbus_enable="YES"

And the following lines in /etc/X11/xorg.conf:

Code:
Section "ServerFlags"
Option "AllowEmptyInput" "false"
EndSection

I then added following lines in ~/.xinitrc:

Code:
exec enlightenment_start
#exec wmaker
#exec /usr/local/kde4/bin/startkde

Then launched X by typing startx. Everything was fine, including the resolution, E17, keyboard, and mouse were all working smoothly. I then launched windowmaker, and still everything were working good. Then I switched kde4, and noticed that somthing got strange - nothing in KDE4 was working unless I move my mouse. For example, when I clicked a button nothing happend until I pinch my mouse. I then switched back to E17, but this phenomenom was still there; on E17's default theme when the cursor is hovering above a list there should be "shining" animation moving across the list as well as fading in and out, but now these animations are all freezed - only when I pinch the mouse does everying work a bit. Another example is that, when I wanted to type something in xterm, those characters didn't show up until I move the mouse. In short: when the mouse doesn't move, so doesn't everything (regardless of being a user or root)!

At first I thought the gigantic kde4 was the cause, but then I tried to re-install FBSD7.2 from DVD but only with windowmaker as the window manager but again, everything was fine at first and then the phenomenom came back (before this happened again, I installed thunderbird and pidgin using pkg_add -r). I haven't got time to have a look at /var/log/Xorg.0.log or dmesg at the moment (will check these logs this weekend) but IMHM I don't think I came across with any error message... The system is still usable, but this is extremely annoying...x(

Anyone had this problem before? Any solution or advice would be appreciated.
 
Does it mean I'm supposed to deinstall or upgrade the binary Nvidia driver? (I'm not at my own computer at the moment but I remember that sysinstall installed Nvidia driver as a dependency)
 
I had some similar problem a few years back and it turned out I needed to downgrade the version of the nvidia driver I was using.

I would start with making sure you are using the correct version for you specific card.
 
I had this problem as well.
And guess what i have ATI Radeon....

I recompiled X without HAL support and everything works like charm

p.s.
This problem really pissed me off
 
One thing I cannot understand is that, if it's the Nvidia driver that is causing the problem, then why doesn't the phenomenom occur from the very first stage? It makes me feel that I've done something (click on something, installed something, or whatever) that triggered the problem...

Anyway, how do I know what the correct version for my card is? (besides, since my card is ATI Radeon but not Nvidia, why should I bother the Nvidia driver?)
 
semin said:
Anyway, how do I know what the correct version for my card is? (besides, since my card is ATI Radeon but not Nvidia, why should I bother the Nvidia driver?)

If your graphics card is ATI of course you shouldn't bother with NVIDIA drivers.
 
killasmurf86 said:
I had this problem as well.
And guess what i have ATI Radeon....

I recompiled X without HAL support and everything works like charm

p.s.
This problem really pissed me off
This is most likely the solution.

BTW, you can turn HAL support off in the xorg.conf (of course, you also should deactivate HAL in your rc.conf).
 
Thanks for the workaround. Will give it a try.

However, this shouldn't be the solution for the long run since that X.org is using HAL for controlling hardwares, and it's likely that the problem would be back once X (or FreeBSD itself) is upgraded in the future... Or probably the bug(s) will have been fixed by then... who knows.
 
I have a same problem, but i find interesting thing:]
If you move your mouse slowly to the right, everything became allright... but if you move it to the left - you have to move it all time

What can we do? It's really annoying...

P.S. Sorry for my english
 
Usaaf said:
I have a same problem, but i find interesting thing:]
If you move your mouse slowly to the right, everything became allright... but if you move it to the left - you have to move it all time

What can we do? It's really annoying...

You should write a small program which will move mouse slowly to the right and execute in your .xsession or .xinitrc script.;)
Seriously, how pathetic can we get?


This whole thread is utterly ridiculous. HAL is not mandatory part of X (XOrg) server yet. When it becomes you will know as OpenBSD and NetBSD will not use XOrg implementation of X window system any more.
Things should work properly without HAL support compiled into your X server. If they don't and if you happen to use binary blobs drivers then you remove binary blob drivers. Then you check again. If they are still not working properly you fill in
bug report with X.Org.
 
semin said:
After installing all distributions and packages on the DVD, I copied /root/xorg.conf.new to /etc/X11/xorg.conf, and enabled hal and dbus by adding the following two lines in /etc/rc.conf:

Code:
hald_enable="YES"
dbus_enable="YES"

And the following lines in /etc/X11/xorg.conf:

X server should work 99% of time without any xorc.conf file if it is properly ported to FreeBSD.

I would try to keep things simple and not start hald and dbus daemons. If you want to use HAL, use MAC.
 
i dont use an xorg.conf.
i just ran startx from the beginning without configuring anything and it worked perfectly... after i rebuilt xorg without hal.
 
For the record this is wrong
Code:
Section "ServerFlags"
Option "AllowEmptyInput" "false"
EndSection

It should be in the the ServerLayout section and should read
Code:
Option "AllowEmptyInput" "off"

See /usr/ports/UPDATING for more details. It would have resolved the issue but removing hal is a good thing :)
 
Code:
[root@freeUsaaf /usr/home/Usaaf]# uname -a
FreeBSD freeUsaaf 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May  1 08:49:13 UTC 2009     root@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
dmesg
View attachment my_comp.txt
---
Xorg.conf
View attachment xorg.conf.txt
---
Pkg_info xorg_server
View attachment xorg_server.txt
---
Pkg_info gnome2
View attachment gnome2.txt

My problem seem to be solved:] But now i have no mouse in my console...
Just turn off moused in rc.conf and all problems with mouse dissapear

rc.conf
View attachment rc.conf.txt
 
BuSerD said:
For the record this is wrong
Code:
Section "ServerFlags"
Option "AllowEmptyInput" "false"
EndSection

It should be in the the ServerLayout section and should read
Code:
Option "AllowEmptyInput" "off"

See /usr/ports/UPDATING for more details. It would have resolved the issue but removing hal is a good thing :)

This is not correct.

xorg.conf bolean options such "AllowEmptuInput" accept values such as "true", "1", "on", "yes" to turn the option one; or to turn then off "false", "0", "off" or "no". Also option name and values are case insensitive.

So
Code:
:
Option "AllowEmptyInput" "Off"
Option "AllowEmptyInput" "off"
Option "AllowEmptyInput" "False"
Option "AllowEmptyInput" "false"
Option "AllowEmptyInput" "no"
Option "AllowEmptyInput" "0"
Option "AllowEmptyInput" "FALSE"

Are all the same.

xorg.conf(5) for more info.
 
semin:
I had exactly the same problem: little or no keyboard response until
I moved the mouse. I cured it by removing the option
"AllowEmptyInput" "False". Doing so seemed to allow HAL to do its job.
This is with Xorg 7.4.
 
mdg said:
semin:
I had exactly the same problem: little or no keyboard response until
I moved the mouse. I cured it by removing the option
"AllowEmptyInput" "False". Doing so seemed to allow HAL to do its job.
This is with Xorg 7.4.

i second this. i had the option enabled before but it started acting up at some point after some upgrades
i don't have it enabled anymore and everything is fine, but it did that some testing first, since it was worse when i was using either gdm or kdm as login manager. i'm using slim now and as mentioned that option is not in my xorg.conf.
 
I had the same problem: little or no keyboard response until
I moved the mouse. I also cured it by removing the option
"AllowEmptyInput" "False" i xorg.conf.

My problem started with a freeze making a DVD and hard reboot. No new software usage or install. It feels like a crashed config or tmp file.
 
Back
Top