X11 7.7 Released, Brings Multi-Touch Input 128
First time accepted submitter Jizzbug writes "The X Window System made release X11 7.7 last night (June 9th): 'This release incorporates both new features and stability and correctness fixes, including support for reporting multi-touch events from touchpads and touchscreens which can report input from more than one finger at a time, smoother scrolling from scroll wheels, better cross referencing and formatting of the documentation, pointer barriers to control cursor movement, and synchronization fences to coordinate between X and other rendering engines such as OpenGL.'"
i thought xorg buried x a long time ago (Score:2)
i thought xorg buried x a long time ago. x is the cat with 11 lives. rimshot.
Re: (Score:2)
You are thinking of XFree86.
Wht not sound? (Score:5, Interesting)
X virtualises user interface devices: mice, keyboard, display. Why sound has always been outside? Is not it another part of user interface?
Why we have these incompatible "sound servers", if the X protocol could be used instead? Tunneling a video with sound through X through ssh through Internet? No problem.
Re: (Score:1, Funny)
THIS is a very important idea. Sound is blocked from the X protolcol by an Italian-Apple conspiracy funded by the Vatican and the CIA to keep X from its rightful place as the Queen of Multimedia Web 3.0 Compurtrterizining.
Re:Wht not sound? (Score:5, Funny)
It's hard enough getting sound to work well locally
Nah, just try "apt-get purge pulseaudio".
Re:Wht not sound? (Score:5, Interesting)
Re: (Score:2, Informative)
It used to be very crash prone, laggey and with a whole lode of audio glitch issues. It has not caused any serious issues for me for about 2 years now, and complaints form new users have dropped dramatically so it seems to have improved quite a bit. You do not want to use it for low latency audio and there are a few specific pieces of hardware that do not work but most complainers either oppose its design principles or still hate it due to long memories rather than current issues.
Re: (Score:1)
It still takes way too much CPU for what it does. ALSA is much, much better in that regard.
Re:Wht not sound? (Score:4, Informative)
I recently updated from debian squeeze to wheezy, and in the process it reinstalled pulseaudio. Surprise, surprise: my computer crashed frequently until I got rid of it again.
Sound on Linux has been very problematic the entire time I've been using it -- since the late '90s. It's turned into this weird tinker-toy arrangement where nothing quite works right, and debugging problems when you have them is extraordinarily painful.
Right now, the best solution I've found is to nuke all of the ALSA, pulseaudio, and other userland crap and go with OSSv4 -- it's been very stable for me over the last few years, and since it's self-contained at least solving problems doesn't take finding a needle in a haystack. The biggest downside is that (at least, AFAIK), it's not supported by mainstream distros, so if you're not comfortable recompiling your kernel and modules it's not usable.
Re: (Score:2)
If PulseAudio can make your computer crash, then you've got bigger problems than PulseAudio. Probably broken audio hardware drivers.
Re: (Score:2)
Maybe, maybe not. Depends on what someone means when they say "crash". For instance, suppose your desktop environment suddenly crashes, leaving you back at a login prompt and losing all your work. To most users, that's a "crash", even though there may be no problem at all with the kernel or drivers, only with the desktop environment which runs in userspace.
Re: (Score:3)
Yes, but I don't think those users would compile OSSv4 to get around ALSA and PulseAudio's failures.
Re: (Score:1)
Re: (Score:3)
So, what are you supposed to use it for? Given that gaming isn't exactly Linux's forte, and audio production is a more likely niche, which requires low latency audio, what problem is pulse trying to solve. Having multiple audio solutions because the primary one can't do low latency is retarded.
Meanwhile, FreeBSD has done multi-channel audio out of the box without any grief since at least 2005.
Re: (Score:1)
What makes it so bad, it sits between stuff that does something and the application your using, replicates functionality of pre-existing applications whilst increasing latency and when things do go wrong it seems that purging it from the system has so far done wonders.
YMMV so enjoy, I haven't found a compeling reason for it yet other that its widely adopted and getting harder to avoid. That does not make me smile.
Re: (Score:2)
Compelling reason for it? It makes my microphone work right in TF2 via Wine(likely because of resampling - Audigy 2 sound card).
For everything else on that system, ALSA is fine with defaults due to the hardware mixer on that card.
On other systems however... I've had great luck with it on my laptop and it's crummy DAC, abd especially being able to hotplug a USB DAC and have the sound come out of there automatically. And I didn't even have to edit config files!
Lag is still an issue, but there's a environment
Re: (Score:2)
Blue tooth audio devices?
I realize you don't have any, but if you try getting it to work you will discover that pulse audio is the only solution on linux.
Pulse audio exists because OSS, ESD, ALSA, jack, and whatever else there is cannot provide universal plug and play audio for linux. Pulse Audio has had a long road to travel, and it is not truly finished, but it is getting close to plug and play audio in a lot of situations.
Re:Wht not sound? (Score:5, Interesting)
I think the reason people don't like it is that it introduces a fair number of problems, and it only has benefits in some rare, specific circumstances
Pulse seems to have been introduced at the wrong level, for what it is. Because it works on top of ALSA, it relies heavily on some little used functions, such as getting the true decibel level of the volume controls. (This causes the PA volume controls to fail for some hardware, such as muting the audio at 25 %). On the other hand, it doesn't make use of all ALSA functions, so it does resampling and mixing in software, instead of relying on (possibly superior) hardware. It also doesn't expose all functionality of the underlying devices, and I think it was difficult to get passthrough of digital audio to work about 6 months ago. So it's a rich API built on top of another rich API, offering little benefit, and introducing some bugs.
Re: (Score:2)
Re:Wht not sound? (Score:5, Interesting)
BSD people look at you strangely if you try to get Pulse working
That's because Pulseaudio was designed to solve issues that for the most part have never existed on BSD systems. The BSD's evolved their existing OSS based audio subsystems to fix the few issues it had, whereas Linux chose to adopt a poorly implemented new system. I speak from experience, having tried to write an OSS shim for NetBSD that emulated the ALSA MIDI API, and became frustrated by the incomplete, innacurate documentation. I was also bemused by the ALSA API itself which looked like it was designed to be object oriented, but actually implemented by people with no real understanding of good OO princples.
Re: (Score:2)
BSD = load appropriate sound module. Run application. Enjoy multi channel sound.
Re:Wht not sound? (Score:5, Interesting)
To be honest, I agree with it's choice to hardware mix/resample in software - Most cards(by volume) are just dumb DACs, and the few that aren't(like my audigy 2) have enough bugs to make it useless to try - Just use ALSA straight on those cards, or only use Pulse for that application(which works perfectly well when you have a hardware mixer).
Re: (Score:3)
In my experience Pulse will sometimes not work at all, and other times when you change the system volume it will lag on changing quite a bit or make the sound mute briefly.
I had a much better experience overall with ALSA and ESD.
Re:Wht not sound? (Score:5, Interesting)
Right before Ubuntu brought in Pulse, I'd finally hit a sweet spot with Linux audio. With ALSA + qjackctl I was able to manage low-latency multitrack audio recording, and simultaneously have discrete control over the audio of all media players. Before pulse, I was able to use my terminal as a giant mixing board, managing recording and various media playback simultaneously. Different mixes and levels for different apps -- I was able to discretely control the audio levels and mixes for *each channel* in surround sound.
Pulse completely destroyed these capabilities, it eliminated the low-latency capability necessary for multitrack recording, and replaced it with frequent crashes, inconsistent behavior, and was tied in so deeply that Ubuntu has never since been capable of the audio layout I'd been using about five years ago.
Pulse is the single worst Linux move I've ever seen. In the interest of removing audio from the kernel space (necessary for low-latency), it simply eliminated what used to be advanced capabilities. Lennart Poettering, author of Pulse simply disregarded these concerns, waved his hands and said "that's not the concerns Pulse was designed to address!"
No shit, Lennart.
Re:Wht not sound? (Score:5, Interesting)
It's really time for the kernel guys to take another look at OSS4. Fully GPL compatible, it belongs in the kernel.
Re: (Score:3)
Re: (Score:2, Interesting)
Since you're flaming, I can flame harder.
Disclaimer: I've sent some patches to pulseaudio and alsa.
Pulseaudio is possibly the best thing that has ever happened to linux, the introduction was unquestionably problematic, but dmix that it replaced will not be missed. It also contains features that decrease the amount of interrupts needed, and it didn't work around problems in hardware but fixed. If you feel like it you can STILL use jack, in fact with -rt kernel I ran pulseaudio on top of jack in a 2.5ms maxim
Re: (Score:2, Informative)
Pulse killed the possibility of
Why not use jackd directly on top of alsa and pulseaudio as a client for jack? You could use pulseaudio for all desktop stuff that doesn't need low latency which I believe would only use one jack slot (or whatever it is called) and all latency critically things could connect directly to jack.
pacmd suspend true
sudo jackd -d alsa
pactl load-module module-jack-sink channels=2
pactl load-module module-jack-source channels=2
pacmd set-default-sink jack_out
pacmd set-default-source jack_in
pacmd suspend false
Or someth
Re: (Score:2)
So... do what every one else does.... DONT USE IT!
I removed it via a hack... by doing a force hack mv on the pulsecrap bin... hackish very hackish.
Now I just remove the packages in synaptic and let ALSA take over in Phonon like it should.
So just remove it and go back to doing what you were doing.
Yes its an uneeded and annoying to have to do this, but just like the other PITA project, WAYLAND, the too young to have been alive when X or ALSA came about have their heads buried on what is the "better path."
Re: (Score:2)
Re: (Score:3)
Multitrack recording is where you record a track or tracks while listening to and playing along with a prerecorded track. This requires extremely low latency -- you need to be able to play something and hear it back as close to instantaneously as possible. Latency needs to be at a lower ti
Re: (Score:2)
BSD architecture allows real time interrupts to kernel space. It's just that almost all the drivers these days use ISR threads that are woken up by an interrupt.
There's nothing stopping a carefully written driver doing everything in the ISR.
Re: (Score:2)
So you really think a human can perceive a sound desynchronization of six MILLIONTHS of a second? That's a period in which sound travels two MILLIMETERS. You could move the position of your head imperceptibly and incur a delay of that much. Do you really think moving the violins 2 mm with respect to the horns is going to be perceptible in a concert hall?
Do you want to try that again?
Re: (Score:2)
Re: (Score:2)
>> Different mixes and levels for different apps
Weird... I wanted that feature, and that's exactly why I was installing PulseAudio for a year before Ubuntu picked it up as a standard. PulseAudio makes per-app mixing just work, whereas before Pulse came around I had never seen any OS do that since the BeOS.
Re: (Score:2)
Indeed. Fuck Pulseaudio.
It lies at the majority of the problems I have with my WebOS phone. Why they chose pulse on a device that DEPENDS on doing audio with multiple sources and outputs simultaneously is beyond me. Buggy and unreliable as hell.
Fuck pulseaudio.
Re:Wht not sound? (Score:5, Insightful)
Because the distros put it in way the hell to early, a point at which there were plenty of kinks, and the benefits had not been made visible in a meaningful way in any UI I noticed.
There's only so many times you could end up with random sound problems which were solved - with no loss of functionality - by killall pulseaudio - or more permanently...
rm /usr/bin/pulseaudio /bin/cat /usr/bin/pulseaudio
...without developing a certain animosity towards that binary.
ln -s
Re: (Score:2)
Hmm. This sounds a bit like the KDE4.0 fiasco, except there the KDE guys stupidly said it was ready for mass adoption, even though it clearly wasn't. And then they did the exact same thing with GNOME 3.0.
It seems the Linux distro maintainers really don't bother to test their builds very much.
Re: (Score:2)
They said that after the users raised hell about the alpha quality of the software. It wasn't mentioned on the KDE website because I looked when I first upgraded.
Re: (Score:2)
Some years back it was quite tricky to get working in distributions that didn't pre-configure it, required equal proportions of skill and dumb luck. If you stuck to the more user friendly stuff like ubuntu, mint, etc. it's likely you never would have experienced issues. I remember a great deal of frustration before finally just going back to alsa with arch. Damn thing was impossible...
But, like the former difficulty of wifi, it's mostly a distant memory. Mostly...
Re: (Score:1)
I've been using Ubuntu/Xubuntu for the last 6 years, and I like playing games in emulators like MAME and Mednafen. Pulseaudio causes delays, sometimes of several seconds, with the libsdl pulseaudio package installed.
I have a simple 14 dollars Sound Blaster Audigy SE PCI card.
Purging Pulseaudio and using plain ALSA makes all of my sound problems go away.
The sound lag in some emulators is gone. I can even watch movie files with 5.1 surround sound without any problem, and several sound outputting applications
Re: (Score:2)
Not the only one. Hell, I was setting up pulseaudio by hand for a year or so before it became the standard on Ubuntu, just because it made things work _so_ much better.
However, the reports of it borking things are consistent enough to convince me we might be in a minority.
Re: (Score:2)
I've never had a problem with it either. I also quite like Gnome 3, systemd, etc. Satisfied people are less likely to make a song and dance about their experiences though, so the moaning always dominates.
Re: (Score:1)
ditto, it works
Re: (Score:2)
They don't whine and bitch and moan. So they are far less visible. That's the problem with stuff in general. Most people that aren't having problems simply aren't motivated to declare that things are fine.
Re: (Score:2)
I use pulseaudio on two different computers, on Linux Mint and Kubuntu. Never had any problems with it.
That said, I don't know that it's the greatest solution to the problem. It seems like OSS4, where multiple programs can write to /dev/dsp simultaneously (as I understand it), is an architecturally superior solution to doing this in userspace. Then again, it seems like it'd make even more sense to build sound into X (or its successor), so that people running remotely will have both video and audio redire
Re: (Score:1)
>> It's hard enough getting sound to work well locally
>
> Nah, just try "apt-get purge pulseaudio".
Nah. Just use "apt-get remove lemming-trolls"
Re:Wht not sound? (Score:4, Informative)
Re: (Score:3)
Sound works fine on FreeBSD, no need for ugly hacks like PulseAudio, just in-kernel low-latency sound mixing and a full OSS4 implementation, complete with per-application volume controls, surround sound, and all of the features you'd expect of a modern operating system.
That's one thing the BSD's got right. However Linux had an old and unmaintainable version of OSS, so ALSA had to kill it off in Kernel. PulseAudio is a nasty bloated buggy piece of crap, even old ESD works far better IMHO.
So the same guy that made system boot configuration and init scripts a huge pain in the ass with systemd is also responsible for screwing up our sound support? Somehow I am not surprised by this....
Amen!
Re: (Score:2)
Why sound servers shoud be compatible? Just stick with PA and be set. Or JACK with plain ALSA, if pro sound is your thing.
Re: (Score:1)
It was called 'NAS': Network Audio System. AFAIK it was output only, supported stereo audio, and had more or less died out by 2005. I used it a bunch prior to that as a much much reliable replacement to ESD/pulseaudio however. It just worked, allowed me to stream audio to remote X sessions, and did it with pretty low network overhead. As a bonus it used whatever your DISPLAY variable was set to as the remote end.
Re:Why not sound? (Score:5, Informative)
The X Consortium (the follow-on to the MIT X Consortium, i.e. the original x.org) started to do audio back around 1994.
Nobody gave a toss then and the project died when the consortium folded at the end of 1996.
And BTW, before that there were two competing audio extensions, one from DEC and the other from NCD IIRC, and neither one caught on.
Re: (Score:2)
Here's a hint. X is a visual interface and ends up on the monitor. Sound is audio and ends up in the speakers. Keyboard and mouse are completely inseparable from the visual interface and sound is not.
Re: (Score:2)
Re: (Score:1)
Re: (Score:1)
Please Specify which X implimentation (Score:1)
Re: (Score:2)
There is only one X implementation that makes new versions of X.
Ahh yes, jizzbug (Score:1)
Wise words from a wise man
Isn't it a little late? (Score:2)
Maybe we'll evolve this way past the Xorg.conf and its documentation, good riddance, moving from a wrinkled legacy to a more sane and friendly approach. I love X when it works, it's unbearable when it doesn't.
Wayland (Score:2)
Re: (Score:3)
"The UNIX world is becoming very Linux- and GNU-centric."
So much for being portable and flexible.
Re: (Score:2)
It depends on kernel mode setting. There's nothing Wayland depends on that can't be implemented by FreeBSD.
Re: (Score:2)
Re:Wayland (Score:4, Insightful)
Wayland's current status: it continues to be the vaporware windowing system that is the darling of people who have no idea about what X really does or what its problems might be.
Re: (Score:1)
Except one of the biggest contributors to Wayland is Keith Packard, the guy who forked X.org from XFree86. I'm pretty sure he has a good grasp on windowing issues. Not sure he's the person to write something from scratch, though, especially when all the low-level I/O details were already worked out decades ago; they don't have any experience with viable alternatives. The RPC mechanism in Wayland is truly horrendous.
Re: (Score:1)
Even though my sarcasm didn't climb this tree of comments, I'm happy I got to read a comment to he point. Thank you.
Brings as in it's now part of.... (Score:5, Informative)
X has had multi touch for YEARS. It was a patch. it's only now that it's a part of the official.
Does it only record multi-TOUCH events? (Score:3)
Re: (Score:2)
Using X's power? (Score:2)
I've actually played around a bit with X Windows's remote windowing feature, which was around years before MS put similar functionality in Windows, but it was a pain to set up and get it working.
Are there any window managers/desktop environments that can utilize X's more esoteric features like these in a simple, uncomplicated fashion? Preferably without messing with the command line.
Re:Using X's power? (Score:5, Informative)
Despite your dig at the command line, it really doesn't get any simpler than 'ssh -X remotehost remoteapp'.
Re: (Score:3)
I'm sure you can write a wrapper where you have to click at least a dozen times to select the remote host and app.
Re:Using X's power? (Score:4, Interesting)
If you want to do something like Sun, where you authenticate and it finds your session out there and pops it up on your machine, that's a bit more complicated. Pretty cool, but more complicated.
Its a pain to set up if you're an idiot (Score:4, Informative)
"but it was a pain to set up and get it working."
Yup, I mean look at these examples for how devastatingly complicated it it:
"xterm -display [host ip]:[display id]"
or if you're feeling even more l337:
export DISPLAY=[host ip]:[display]
xterm
But I guess if you wet the bed at the thought of having to use a keyboard instead of a mouse then you're pretty screwed.
Re: (Score:2)
Maybe the OP is talking about enabling incoming X connections. This varies with the display manager and its release, and sometimes does require the edition of a non obvious configuration file.
No it doesn't (Score:2)
"xhost +"
Sorted.
Re: (Score:2)
"xhost +"
Sorted.
Except that current distros tend to have -nolisten tcp by default.
Re: (Score:2)
"xhost +"
Sorted.
This blatant security wole should be down-modded. You sir, should be ashamed of yourself. (unless you were just trolling, in which case, well played).
Re: (Score:2)
'remote windowing feature'? That's like saying http has a 'remote web page download feature' because you can connect to an http server from another machine. The whole point of X is that it is a network protocol from the ground up. It's designed for environments where applications are run over networks; unfortunately nowadays the PC model of computing has won, which is why 'remote windowing' looks like an extra 'feature'.
Re: (Score:1)
'remote windowing feature'? That's like saying http has a 'remote web page download feature' because you can connect to an http server from another machine. The whole point of X is that it is a network protocol from the ground up. It's designed for environments where applications are run over networks; unfortunately nowadays the PC model of computing has won, which is why 'remote windowing' looks like an extra 'feature'.
It MAY LOOK this way, but "cloud" computing is nothing more than the resurection of time share systems of the past on mainframe and minis.
XDMCP and X via SSH will play an even more important role in this "new cloud" world.
The fact that the developers of certain software, cough wayland cough, was not even alive when X and thin computing or using a TTY60 on a dial up modem, shows that forgetting history is just as applicable to computer/technology as it is to the real world.
And NO the "PC model" has not won..
Re: (Score:2)
It MAY LOOK this way, but "cloud" computing is nothing more than the resurection of time share systems of the past on mainframe and minis.
Only if you define "cloud computing" as "running jobs on shared infrastructure with quotas". Mainframes and minis of the past didn't have replicated filesystems, didn't scale to multiple sites and certainly didn't let you run potentially untrusted code in a sandbox.
Cloud computing is to car pooling as a mainframe is to mass transit. It's certainly cheaper and more efficient to send 1000 people from A to B by bus or train than to use the equivalent number of cars, but it only works if a critical mass of peop
Direct video access? (Score:2)
Did Linux ever get an equivalent to DirectDraw? I know there is svgalib, but I thought that was equivalent to full screen DOS programs on Windows 98, since it could not share the screen. The news about coordinating rendering engines sounds neat, like you could safely get access to video memory and bypass any windowing systems, but still cooperate with a windowing system.
Re: (Score:1)
Does DRI qualify?
Re: (Score:1)
Not exactly, but the concept of direct access to video memory became unimportant. There's really no use for it at this point. Graphics hardware is sufficiently complicated that there is no useful way to "just get a pointer to video memory." The concept really no longer exists. If it did exist, it would be completely different on different hardware. And, it would be horribly slow.
Instead, you have OpenGL. You can make a texture on the CPU, upload it to the GPU, and draw it while "cooperating with the w
Re: (Score:2)
That would be why X running with framebuffer runs slower than X talking direct to hardware on both of my machines I suppose? (X is an application btw)
Re: (Score:2)
"The Linux framebuffer is a way to write directly to the video framebuffer"
No , the linux framebuffer is essentially abstract video hardware so the video drivers can be moved into the kernel instead of X windows having to have them. Unfortunately this means every write to the display now has to go via the kernel instead of going direct. X using its own specific video card graphics drivers avoids this and is in consequence a damn sight faster. And the programs I tested were using base Xlib on a raw X server
Re: (Score:1)
Unfortunately this means every write to the display now has to go via the kernel instead of going direct.
No, if you mmap() the framebuffer you (as in the application) write directly to video memory (of course, what you say is true if the application uses lseek() and write() instead, but why would it?). The reason it's slower is because drivers make the GPU do all the heavy lifting. The only abstract thing about the Linux framebuffer is that you don't have to map the memory yourself, the kernel drivers do it for you.
NX technology? (Score:1)
Compiz (Score:2)
Maybe we will get some active development on compiz, or something equivalent again to take advantage of all of the cool things you could do with this.