# X.org 7.5 Released



## DutchDaemon (Oct 27, 2009)

> The X.Org Foundation and the global community of X.Org developers announce the release of X11R7.5 - Release 7.5 of the X Window System, Version 11.  This release is the sixth modular release of the X Window System. The next full release will be X11R7.6 and is expected in 2010.



http://lists.freedesktop.org/archives/xorg-announce/2009-October/001187.html

(note: 'released' does not mean 'available as a port or a package on FreeBSD')


----------



## Beastie (Oct 27, 2009)

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.


*sigh*, how about investigating *no* alternatives? I'd like that very much.


----------



## SirDice (Oct 27, 2009)

Beastie said:
			
		

> *sigh*, how about investigating *no* alternatives? I'd like that very much.


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.).


----------



## graudeejs (Oct 27, 2009)

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.




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.


here we go again (I hope not)


----------



## fronclynne (Oct 27, 2009)

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.).



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.


----------



## SirDice (Oct 27, 2009)

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.


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.


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.).


----------



## aragon (Oct 27, 2009)

SirDice said:
			
		

> I really would like to have something that automagically detects mice, keyboards


I suspect I don't need to point these out, but will anyway: 

moused(8)
kbdmux(4)




			
				SirDice said:
			
		

> even graphicscards without having to shutdown X


Ok, that's a little harder.


----------



## Beastie (Oct 27, 2009)

SirDice said:
			
		

> So all we need now is a DeviceKit that uses the already existing FreeBSD framework and we should be good to go.


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 (Oct 27, 2009)

aragon said:
			
		

> SirDice said:
> 
> 
> 
> ...


Oh, you just use one of those PnP hot-swappable graphic cards. P


----------



## mickey (Oct 28, 2009)

Beastie said:
			
		

> Oh, you just use one of those PnP hot-swappable graphic cards. P



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?


----------



## fronclynne (Oct 28, 2009)

*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?



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.


----------



## SirDice (Oct 28, 2009)

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.



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.


----------



## SirDice (Oct 28, 2009)

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?


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).


----------



## mickey (Oct 28, 2009)

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.



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).



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.


----------



## Beastie (Oct 28, 2009)

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.


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.


----------



## SirDice (Oct 28, 2009)

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?


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.


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


----------



## adamk (Oct 28, 2009)

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.



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


----------



## Dru (Oct 28, 2009)

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.



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.


----------



## mickey (Oct 28, 2009)

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.



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.


----------



## fronclynne (Oct 30, 2009)

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.


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?


----------



## copypaiste (Oct 30, 2009)

Great news! Maybe I can hope that darn intel video would work again (as it was once many moons ago).


----------



## adamk (Oct 30, 2009)

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.



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


----------



## Beastie (Oct 30, 2009)

copypaiste said:
			
		

> Great news! Maybe I can hope that darn intel video would work again (as it was once many moons ago).


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.


----------



## Beastie (Oct 30, 2009)

adamk said:
			
		

> If it's something you really dislike, don't use Xorg.


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.


How about using the Scroll Lock key when it goes verbose?


----------



## Shura (Oct 30, 2009)

Hi,
Anybody installed it with ATI card?


----------



## SirDice (Oct 30, 2009)

Shura said:
			
		

> Hi,
> Anybody installed it with ATI card?



It's not in the ports yet so I doubt anyone has.


----------



## phoenix (Oct 30, 2009)

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.



Using portmaster to install/manage your ports would prevent this, as it saves all the pkg-messages from each port it installs, and then displays them all at once, using $PAGER, at the end of the install.


----------

