Xorg 7.4 clean install

zeiz

Aspiring Daemon

Reaction score: 57
Messages: 691

I tried to upgrade Xorg 7.3 > 7.4 and I broke my installation.
So I installed FreeBSD 7.1 as base+kernel+docs from FTP, then pumped ports through cvsup and installed Xorg 7.4 (xorg-server 1.5, vesa driver 2.1). Just startx didn't work as it was in 7.3. X -cofigure failed but I got xorg.conf.new that had 17 monitors, 17 videocards and 17 screens with 5 displays in each :)
I left only one mode, chose vesa driver, entered monitor's properties, and line "Modes" in Screen section. X fired up but neither mouse nor keyboard was working. I tried "moused..." tricks in rc.conf and it didn't work. Others didn't work too.
Finally I got beautiful X by putting hald_enable="YES" in etc/rc.conf :)
 

ale

Daemon

Reaction score: 169
Messages: 1,059

@vermaden
If I've understood what you are asking, as I've said on another thread, I've always built xorg-server using WITHOUT_HAL since the option appeared.
Now it works fine and moused is still enabled and working.
The only thing I have to do is to add the line about AllowEmptyInput to my xorg.conf as in UPDATING.
Another thing that I have to do is switching the nvidia-driver from the one in ports to the latest from nvidia web site. I think that there is solution to still use the one in ports, like creating a link or something, but until a new version will be committed I'm happy with this one.
Not considering the problem about nvidia driver, and the fact the a lot of ports was rebuilded, I didn't had any particular difficulty.
Ah, gmplayer is b0rked. :(
 

trev

Daemon

Reaction score: 298
Messages: 1,020

zeiz said:
Finally I got beautiful X by putting hald_enable="YES" in etc/rc.conf :)

As ale points out, building xserver without HAL and inserting AllowEmptyInput "False" in the ServerFlags section of xorg.conf also allows everything to be as it was before (at least in relation to the keyboard and mouse devices).
 
OP
zeiz

zeiz

Aspiring Daemon

Reaction score: 57
Messages: 691

Why not to use HAL?
Also I cannot recall "SeverFlags" section in xorg.conf
In the fresh installation notice the same port's maintainer who offered 2x"moused...="NO"" OR AllowEmptyInput "off" in ServerLayout section now wrote that he fixed things and 7.4 should work without those tricks. My pure X works fine, I'm building Gnome now, we'll see...
 

hydra

Well-Known Member

Reaction score: 27
Messages: 272

Is this the answer ?

Code:
20090123:
  AFFECTS: users of x11-servers/xorg-server
  AUTHOR: rnoland@FreeBSD.org

  Server 1.5.3 also really wants to configure its input devices
  via hald.  This is causing some issues with moused and
  /dev/sysmouse.  There are a couple of options for how to deal
  with it.
 
OP
zeiz

zeiz

Aspiring Daemon

Reaction score: 57
Messages: 691

From the same source (usr/ports/UPDATING):

20090124:
AFFECTS: users of x11-servers/xorg-server, sysutils/hal
AUTHOR: rnoland@FreeBSD.org

sysutils/hal has been updated and should now properly detect
mice for use in Xorg. Use of AllowEmptyInput should no longer
be needed for most users and moused should now work fine.

On the other hand... I just installed Gnome 2.24.3 from ports (took me 3 days:). Login screen doesn't contain my user name ("others" instead) and...again neither mouse nor keyboard are working :(
It's possible to start gdm by logging in to X first. In this case mouse and keyboard are working and Gnome is working after logging in. Though...there are 2 "others" in login dialog. Strange...
 

jwhendy

Member

Reaction score: 2
Messages: 60

YES!!!!! Thank you for this post. enable_hald worked for me! Xorg 7.4 came out between the last time I had FreeBSD up and going and now, so I was so puzzled about mouse/keyboard not working. I swore to myself that I had it going fine the last time and just couldn't figure out what I did differently this time around...

There hasn't been a final verdict on this post, though, has there? Should one build without hal or use the enable_hald option in rc.conf? I'm very new and all I really know about hal is it stands for hardware abstraction layer. Other than that, I'm clueless... Is on of these the better option? Would my mouse/keyboard have worked if I built it without HAL?


-John
 

ale

Daemon

Reaction score: 169
Messages: 1,059

jwhendy said:
Should one build without hal or use the enable_hald option in rc.conf?
You can also do both.

jwhendy said:
Would my mouse/keyboard have worked if I built it without HAL?
As I've said before, yes. And probably even better.
For example, from what I've understood, now to specify the layout of your keyboard you have to edit a hal configuration file.
And does your mouse work on ttyv[0-7]?
 
OP
zeiz

zeiz

Aspiring Daemon

Reaction score: 57
Messages: 691

Not a verdict just some more experience. First I noticed that hal bumped couple of times. I gave up with amd64 (no any advantage noticed only problems) and installed 8.0-CURRENT-i386 from ftp. Then I built everything of Xorg 7.4 from source (took a while) and enabled dbus and hald first. After reboot I ran X -configure and edited xorg.conf. Next reboot I successfully logged in to twm with correct resolution (no more ModeLine required) and working keyboard and mouse. Everything worked so fine that I installed KDE4.2 (took quite a while) from source before anything else. I enjoy now fully functional machine and I don't even know what other improvements could be done.
Well, I'm just a user and I judge from user's point of view. I guess my mouse works on tty0 but as to other ttys I could check if I knew how (help appreciated :) Though I can expect some problems because I have 2 mice in dmesg (one of them is a keyboard) but it's not related to Xorg7.4.
Simple common sense says that by time when I would need more ttys our devs would fix everything with new Xorg and other older components that could affect its performance at this moment.
 

jwhendy

Member

Reaction score: 2
Messages: 60

Cool - thanks for the reply I was just curious. After adding 'enable_hald=YES' to rc.conf, I got an error about dbus, so I added 'enable_dbus="Yes"' as well. Now all seems to work fine. The 'checkered screen' with an 'X' for the cursor shows up for a while before the xfce bootsplash, but that's the only thing wrong I can figure right now.

I'll have to look into hal and dbus to figure out what they do - i'm curious myself, but imagine I can get all I need from the handbook and wiki.

Thanks for posting your solution. All works for me! I was so baffled on why I could move my mouse from the console but not after starting x.org!


-John
 

jwhendy

Member

Reaction score: 2
Messages: 60

ale said:
You can also do both.

As I've said before, yes. And probably even better.
For example, from what I've understood, now to specify the layout of your keyboard you have to edit a hal configuration file.
And does your mouse work on ttyv[0-7]?

Which port contains the options? I have been using portmaster, but believe that it re-installs all depends if you update/reinstall one port. I'd like to try the non-hal method, but am not sure which port to re-make (and change the config options) to try this.

Is it just /usr/ports/x11/xorg?

I originally tried looking at the options for /usr/ports/x11-drivers/mouse but there were no options for it...

Thanks for the help.


-John
 
OP
zeiz

zeiz

Aspiring Daemon

Reaction score: 57
Messages: 691

jwhendy said:
After adding 'enable_hald=YES' to rc.conf, I got an error about dbus, so I added 'enable_dbus="Yes"' as well.
Hopefully it's just a typo because in rc.conf supposed to be:
dbus_enable="YES"
hald_enable="YES"
 

jwhendy

Member

Reaction score: 2
Messages: 60

Thanks for the reply, ale. I did find out that it was that port... I just did 'pkg_info |grep xorg' and looked at the options for xorg-7.4 and xorg-server. xorg-server turned out to be the ticket. My results, however, were not great...

First I did 'pkg_delete xorg-server-[version from pkg_info]. It said it couldn't delete it because it was depended on by such and such, but that it would delete it anyway. There were a few dirs that it reported not being able to completely delete, perhaps due to the list file (can't recall exactly).

I did 'portmaster --force-config /usr/ports/x11-servers/xorg-server' and then disabled hal support. I then commented out '[hald/dbus]_enable="YES"' in rc.conf and rebooted. My mouse still worked from the console, but did NOT get picked up in xorg. I redid 'Xorg -configure' and 'Xorg -config /root/xorg.conf.new' with no luck. I changed the device under mouse from '/dev/sysmouse' to '/dev/ums0' to '/dev/ums1' and redid 'Xorg -config /root/xorg.conf.new' each time with no success... I tried re-enabling hald/dbus via rc.conf but with no success.

I redid 'portmaster --force-config /usr/ports/x11-servers/xorg-server' and re-enabled hal support (to try to just use what worked before), making sure '[hald/dbus]_enable="YES"' was in rc.conf (so essentially the settings should have been exactly as they were before re-installing xorg-server) but now my mouse and keyboard would not work.

After getting out of X each time, several (EE) messages were present regarding hal being unable to access the keyboard at atkbd0 and the internal Apple mouse/trackpad. I did not get these the first time and they did, indeed, work. The only difference was that I did not have an external mouse plugged in. Even with it plugged in before, the mouse (external), trackpad, and keyboard all worked with the xorg-server w/ hal and hald/dbus in rc.conf setup.

Any thoughts? I'm open to either how to install xorg-server without hald support or getting back to what worked the first time as long as the final result is a working mouse and keyboard! Could the problem be that I did not re-make all or xorg-server's depends? Do they rely on whether or not hal was enabled in the make options?

Thanks for the input!


- John
 

ale

Daemon

Reaction score: 169
Messages: 1,059

You missed the 1st rule in IT: if it works, don't fix it! :)

There was no need to force to pkg_delete it, forcing the upgrade to have it rebuilt should be enough.
For example, using portupgrade (the one I use) # portupgrade -f x11-servers/xorg-server.

If you have built it without xorg and you are running moused (moused_enable="YES" in /etc/rc.conf) you should use in Section "InputDevice"
Code:
        Option      "Protocol" "auto"
        Option      "Device" "/dev/sysmouse"
but you also have to add Option "AllowEmptyInput" "Off" in Section "ServerLayout" as in /usr/ports/UPDATING, else you mouse and keyboard will not work.

If now you have it built with hal, can you try reconfiguring xorg as in the handbook or trying startx without /etc/X11/xorg.conf?
I really don't think that all the dependencies should be rebuilt after changing the option and also the fact about hald wasn't running during the build should be irrelevant.

Now decide the way you want to take and see if we can have it fixed.
 

jwhendy

Member

Reaction score: 2
Messages: 60

You are right - I should not have tried to fix it ;) I'm all about simplicity, so I guess if I didn't need hal or if hal was a more complicated method for configuring/interacting with the mouse/keyboard, then I'd prefer to not have it, which is why I tried it.

With both hal and no hal, moused was running. I believe it was simply the default via rc.conf. If I don't want it, I needed to add moused_enable="NO". I did try that at one point but did not have success. I did not have the AllowEmptyInput set to off, so maybe that was the issue. My xorg.conf looked the same as what you wrote.

I am still open for the input regarding the 'better' way (hal vs. no hal), although it sounds like there might not be one? I'd also prefer to stick with the method that will be used most in the future (if hal is becoming the default standard for devices, I'd rather use it now than have to change my method later).

I'm at work, but when I get home I will try one of the solutions mentioned. I looked through the man page for portmaster, but am not sure on how to 'upgrade' an existing port. Can I just 'portmaster --force-config /usr/ports/x11-servers/xorg-server' and choose the appropriate hal option? Here's the manpage for reference.

Thanks again for the help.

- John
 

ale

Daemon

Reaction score: 169
Messages: 1,059

jwhendy said:
You are right - I should not have tried to fix it ;) I'm all about simplicity, so I guess if I didn't need hal or if hal was a more complicated method for configuring/interacting with the mouse/keyboard, then I'd prefer to not have it, which is why I tried it.
No problem. I can agree with your reasons.

jwhendy said:
I did not have the AllowEmptyInput set to off, so maybe that was the issue. My xorg.conf looked the same as what you wrote.
I mostly sure that this is the reason why it wasn't working.

jwhendy said:
I am still open for the input regarding the 'better' way (hal vs. no hal), although it sounds like there might not be one? I'd also prefer to stick with the method that will be used most in the future (if hal is becoming the default standard for devices, I'd rather use it now than have to change my method later).
So I think that you should use hal.

jwhendy said:
I'm at work, but when I get home I will try one of the solutions mentioned. I looked through the man page for portmaster, but am not sure on how to 'upgrade' an existing port. Can I just 'portmaster --force-config /usr/ports/x11-servers/xorg-server' and choose the appropriate hal option? Here's the manpage for reference.
As I've said I'm not using portmaster so I couldn't be of any help. Looking at the man pages, it seems that --force-config is needed to run make config again. I would try the -f option (with --force-config if you have to change knob again).
 

jwhendy

Member

Reaction score: 2
Messages: 60

Groovy - I'll try when I get home. So you believe that most will eventually shift to hal for devices, then? Is there a reason that I should choose to avoid hal vs. use it or is it really of no importance which way I go?


- John
 

ale

Daemon

Reaction score: 169
Messages: 1,059

Hal has been introduced recently (about dec. 2007) for xorg-server in ports.
Probably in the future xorg will rely more and more on services provided by hal.
IMHO the sad things are that it's designed with linux in mind, and it's not easy to configure.
The first problem results in great efforts by the porter to have it working on FreeBSD and maybe with half-working features.
The second in the fact that there are many cfg files and they are not plain text, but xml, so somehow more difficult to edit and too prolix. Maybe it's supposed to be configured by a graphical tool.
And IMHO there is not enough documentation for the options.
 
Top