X.org 7.5 Released

DutchDaemon

DutchDaemon

Administrator
Staff member
Administrator
Moderator
Developer
And a new Intel driver (from the same page)! Maybe it'll stop locking the machines up once (or twice) every week. :OO

http://www.x.org/releases/X11R7.5/doc/RELNOTES.html
Input device discovery via HAL

The Xorg server currently uses the HAL framework to discover connected input devices, receive notification of hotplug events for them, and to retrieve configuration parameters for them. The HAL maintainers have deprecated HAL, so the X.Org developers are investigating alternatives. As a result, configuration of input devices via HAL *.fdi files may not be supported in future Xorg server releases.
Click to expand...
*sigh*, how about investigating no alternatives? I'd like that very much.
 
Beastie said:
*sigh*, how about investigating no alternatives? I'd like that very much.
Click to expand...
I really would like to have something that automagically detects mice, keyboards and even graphicscards without having to shutdown X. Preferably customizable (keyboard layout i.e.).
 
from release notes
Input device discovery via HAL

The Xorg server currently uses the HAL framework to discover connected input devices, receive notification of hotplug events for them, and to retrieve configuration parameters for them. The HAL maintainers have deprecated HAL, so the X.Org developers are investigating alternatives. As a result, configuration of input devices via HAL *.fdi files may not be supported in future Xorg server releases.
Click to expand...


It sucks all the way... it sucks because they implemented it, and it suck because later they will remove it.... it's so ************


from wikipedia
As of 2009, HAL is in process of being deprecated in favor of DeviceKit.
Click to expand...
here we go again (I hope not)
 
SirDice said:
I really would like to have something that automagically detects mice, keyboards and even graphicscards without having to shutdown X. Preferably customizable (keyboard layout i.e.).
Click to expand...

I don't really care that xorg can autodetect any more than I care that /bin/cat can, or might want to, autodetect mousies or key-boards. That's an operating system level function, so far as I care.

& on freebsd, at least, I can plug and unplug my mouse day and night, as often and obsessively as I wish, and xorg keeps its fat mouth shut and uses what my operating system tells it to.

& I don't know about you, but I never pull out and replace graphics cards on a running system unless I'm extremely vexed and direly provoked.
 
fronclynne said:
I don't really care that xorg can autodetect any more than I care that /bin/cat can, or might want to, autodetect mousies or key-boards. That's an operating system level function, so far as I care.

& on freebsd, at least, I can plug and unplug my mouse day and night, as often and obsessively as I wish, and xorg keeps its fat mouth shut and uses what my operating system tells it to.
Click to expand...
I can dig that. So all we need now is a DeviceKit that uses the already existing FreeBSD framework and we should be good to go.

& I don't know about you, but I never pull out and replace graphics cards on a running system unless I'm extremely vexed and direly provoked.
Click to expand...
That would be a little extreme :e Regarding graphicscards I'm more or less thinking of autodetecting the correct driver for it and perhaps the possibility (if you have multiple cards) of switching them on/off on the fly. Even with just one card switching from one output to the other would be nice (laptop -> external screen, turning external screen on/off etc.).
 
SirDice said:
So all we need now is a DeviceKit that uses the already existing FreeBSD framework and we should be good to go.
Click to expand...
Why use an additional layer of abstraction, when you can just tell it to use your system's native drivers (just like aragon pointed out)? The required settings are already there in xorg.conf (if you have one) and all you need is to load the appropriate driver at startup.
 
Beastie said:
Oh, you just use one of those PnP hot-swappable graphic cards. :PP
Click to expand...

Probably one of those new USB graphics adaptors :beergrin

I only hope they will never even think of removing the possibility, to configure input devices manually.
Most of my machines have exactly one keyboard and one mouse, and that situation hasn't changed in years. So why would I want some HAL/DeviceKit auto-detect them every time at runtime?
 
Who wants a single point of failure when you can have 65535?

mickey said:
Probably one of those new USB graphics adaptors :beergrin

I only hope they will never even think of removing the possibility, to configure input devices manually.
Most of my machines have exactly one keyboard and one mouse, and that situation hasn't changed in years. So why would I want some HAL/DeviceKit auto-detect them every time at runtime?
Click to expand...

Indeed. A kernel is an abstraction layer. But I guess the more layers you put in between the user programs and the hardware the better stuff works, right? I mean, that's why OSI beat out that cruddy TCP/IP nonsense, right? More complexity = more robust, easier to write applications.
 
Beastie said:
Why use an additional layer of abstraction, when you can just tell it to use your system's native drivers (just like aragon pointed out)? The required settings are already there in xorg.conf (if you have one) and all you need is to load the appropriate driver at startup.
Click to expand...

Because Xorg runs on a lot more platforms then FreeBSD alone. By using a common layer Xorg (and other software too) can use that layer and not worry about the actual implementation in FreeBSD, Linux, Solaris, OS-X etc.
 
mickey said:
Most of my machines have exactly one keyboard and one mouse, and that situation hasn't changed in years. So why would I want some HAL/DeviceKit auto-detect them every time at runtime?
Click to expand...
USB keyboards/mice. They can be plugged/unplugged/changed. Why would I need to restart X if I plug in a mouse or an external keyboard? (think laptops).
 
SirDice said:
Because Xorg runs on a lot more platforms then FreeBSD alone. By using a common layer Xorg (and other software too) can use that layer and not worry about the actual implementation in FreeBSD, Linux, Solaris, OS-X etc.
Click to expand...

Which relocates the same problem to yet another place.
*Someone* has to worry about the implementation details, whether it's HAL, or Xorg. As with HAL, we have all seen, where this path leads. And why is it supposed to be less pain, to hack together some *.fdi file to get a keyboard working, than writing some proper xorg.conf statements?

USB keyboards/mice. They can be plugged/unplugged/changed. Why would I need to restart X if I plug in a mouse or an external keyboard? (think laptops).
Click to expand...

I was not saying, that there is no need for input device auto-detection. But there's also a need for *NO* auto-detection, as *most* users, especially those on desktop machines, will probably never change their keyboard or mouse.
 
SirDice said:
Because Xorg runs on a lot more platforms then FreeBSD alone. By using a common layer Xorg (and other software too) can use that layer and not worry about the actual implementation in FreeBSD, Linux, Solaris, OS-X etc.
Click to expand...
Mice and keyboards already work fine without HAL, and did before HAL was even included in Xorg as a dependency. I've never used HAL and never had any "misunderstanding" issues between Xorg and FreeBSD's native drivers.
HAL created a "solution" to a problem that didn't exist to begin with, and caused problems on its own because, well, it didn't really work as it was supposed to.
 
mickey said:
Which relocates the same problem to yet another place.
*Someone* has to worry about the implementation details, whether it's HAL, or Xorg. As with HAL, we have all seen, where this path leads. And why is it supposed to be less pain, to hack together some *.fdi file to get a keyboard working, than writing some proper xorg.conf statements?
Click to expand...
To be honest I never had any issues with HAL. But what if we learn from the mistakes made with HAL and implement our own DeviceKit? Maybe even add it to the base OS. Sure you would have a different DeviceKit on Linux, BSD and Solaris but as long as the interface to it is standard I really don't see any issues.

And as for adding another layer... Isn't that part of the unix philosophy? Small bits that do one thing and being able to string them together however you see fit?

I was not saying, that there is no need for input device auto-detection. But there's also a need for *NO* auto-detection, as *most* users, especially those on desktop machines, will probably never change their keyboard or mouse.
Click to expand...
Which you could still do, even when Xorg relied on HAL. And I'm sure *most* laptop users will be happy if it did auto-detect ;)
 
mickey said:
I was not saying, that there is no need for input device auto-detection. But there's also a need for *NO* auto-detection, as *most* users, especially those on desktop machines, will probably never change their keyboard or mouse.
Click to expand...

Then don't use HAL (or whatever replacement system the Xorg folks decide to use). No one is forcing you to give up your xorg.conf file.

Adam
 
fronclynne said:
& I don't know about you, but I never pull out and replace graphics cards on a running system unless I'm extremely vexed and direly provoked.
Click to expand...

While I dont have anything important to contribute to this thread, I just had to say thats some funny stuff.


Also...woohoo!!, 8.0 release around the corner, and a new Xorg version, though everything is running so good now, I probably should leave well enough alone for awhile.
 
adamk said:
Then don't use HAL (or whatever replacement system the Xorg folks decide to use). No one is forcing you to give up your xorg.conf file.
Click to expand...

That is exactly what i was saying: They should not give up the possibility, to configure things manually, in preference of some HAL/DeviceKit. Which does not mean, that there should be no auto-detection either. Why not have both, and let the user decide, which fits best.

And guess what... i have compiled xorg-server without HAL support, have proper input device sections in my xorg.conf file, and yet have a proper .fdi file installed, which lets HAL select the appropriate keyboard layout and other options. This way i could either go with or without HAL. I just don't see the point in auto-detecting devices that will never change.
 
adamk said:
Then don't use HAL (or whatever replacement system the Xorg folks decide to use). No one is forcing you to give up your xorg.conf file.
Click to expand...
Well, we had to change compilation options and/or add lines to our previously perfectly functional xorg.conf files for no reason other than the whim of some random ubunutu user who fell off the turnip cart yesterday. It shows a rather shocking lack of both foresight & basic common sense.

I can't see this half-baked notion to stagger over to some new, fun abstraction layer with its own thousands of unforeseen pitfalls going smoothly. I mean, are we going to have to do fourier transforms on 600MB binary files to configure it this time? Maybe "Options DontUnAllowNonEmptyOutputAgain Tralse" for the corker?
 
fronclynne said:
Well, we had to change compilation options and/or add lines to our previously perfectly functional xorg.conf files for no reason other than the whim of some random ubunutu user who fell off the turnip cart yesterday. It shows a rather shocking lack of both foresight & basic common sense.
Click to expand...

Software changes. Deal with it. If it's something you really dislike, don't use Xorg. Or maybe ask the FreeBSD Xorg ports maintainer to not build Xorg with support for HAL (or whatever abstraction layer they decide to use next).

My only real source of frustration was that when installing Xorg from ports or packages, the note that you should enable hald and dbus in /etc/rc.conf was often off the screen before anyone had a chance to read it.

Adam
 
copypaiste said:
Great news! Maybe I can hope that darn intel video would work again (as it was once many moons ago).
Click to expand...
Same here. I have lockups every week. I'm currently experimenting with all H/W acceleration disabled.
Everything is slower and choppier, of course, but even with acceleration on, many things were suboptimal or totally crappy.
 
adamk said:
If it's something you really dislike, don't use Xorg.
Click to expand...
I'm not aware of any *usable* alternative. :OO

adamk said:
My only real source of frustration was that when installing Xorg from ports or packages, the note that you should enable hald and dbus in /etc/rc.conf was often off the screen before anyone had a chance to read it.
Click to expand...
How about using the Scroll Lock key when it goes verbose? ;)
 
You must log in or register to reply here.
Back
Top