Re: FW: A request from the Hackintosh community
Hi, On Fri, Mar 25, 2011 at 01:32:48PM -0300, Felipe Ribba wrote: I'm forwarding this mail trough my Gmail account in case you miss the previous one (I didn't get any replies so far) We did get the original one... But I'm sorry to tell you that this is not the kind of request that is likely to get replies on this list. While people might answer specific technical questions, you can't expect anyone to actively help with something they are not personally interested in. And improving driver support for a proprietary platform is certainly not something people here are interested in. (Quite frankly, it's beyond me why *anyone* would want to spend his time on such things...) -antrik- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Where input (hotplugging) methods might go - highly speculative
Hi, On Fri, Aug 27, 2010 at 12:31:16PM +0200, Wolfgang Draxinger wrote: [...] Such a Console Set combines a number of connected input and output devices Sounds like focus groups in KGI... Too bad the KGI project killed itself with a stupid let's reinvent half the kernel approach :-) There were serveral good ideas in there, which finally find their way into Linux more than a decade later through other projects. -antrik- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xorg-server 1.8.1
Hi, On Wed, May 12, 2010 at 07:56:35AM +1000, Peter Hutterer wrote: The first stable release of the 1.8 series is now available. Only two changes over RC2 (Julien's EXTRA_DIST patch and Adam's VNC patch), so you get the full changelog to 1.8.0 to make this email look more interesting. Hehe :-) This is generally reasonable for final releases though -- I'd suggest making it an official policy... So far this has been handled rather inconsistently. -antrik- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Google Summer of Code 2010
Hi, On Fri, Mar 12, 2010 at 01:22:06PM -0800, Alan Coopersmith wrote: [...] since we always end up with more proposals than Google has funding to cover. Mmm, that sounds like you might not be aware of this: the number of slots assigned to each organisation is first an formost a function of the number of students who applied. So it is *by design* that only the top 20% or so get in. -antrik- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput: Do I want xorg.conf? Do I want hal? Do I want udev?
Hi, On Fri, Nov 27, 2009 at 09:55:22AM +1000, Peter Hutterer wrote: If you don't want a session manager or you prefer a different desktop environment - you're on your own. Let me remind you that GNOME is not an operating system. It is just a frontend. It is nice if it provides a nice shiny tool to configure stuff; but it has no business *storing*, and *applying* such settings, which don't really have anything to do with GNOME at all. These should be pushed down to some generic infrastructure, which is not desktop-specific, and in fact not X-specific at all. Unfortunately, it appears that such a generic session-aware hotplug infrastructure is yet to be invented... -antrik- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
local junk and .gitignore (was: [ANNOUNCE] xeyes 1.0.991)
Hi, On Tue, Oct 06, 2009 at 03:45:45PM -0400, James Cloos wrote: Add *~ to .gitignore to skip patch/emacs droppings As such things are inherently local and specific to your own workflow, IMHO they shouldn't go in the .gitignore in the repository. Luckily -- unlike CVS -- Git offers another way to ignore stuff locally: you can specify extra gitignore files in the configuration. You can even do this globally for all your repositories. For that, add to your ~/.gitconfig: [core] excludesfile = /home/login/.site.gitignore and then create ~/.site.gitignore (or whatever name you prefer) with *~ and other local stuff you tend to have in your working trees. -antrik- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 0/4] Cursor's update inside kernel only
Hi, On Sun, Jan 25, 2009 at 12:28:37PM +0200, Pekka Paalanen wrote: Consider a case where user space is stalled due to excessive load, and let's think about usability. Much of usability comes from feedback given to a user. If cursor updates are done completely inside the kernel, the mouse will continue to work without any hiccups under severe load (this is what you are aiming for, right?). The user clicks a button, and nothing happens in the GUI, since user space is stalled. The user clicks again. And again. Then clicks another button. It takes several seconds for the user to realize, that the clicks are not getting processed. What's worse, all the clicks are probably queued now and will be processed later, possibly leading to unexpected results. If cursor updates had to visit user space, the mouse cursor would stall and jump. This is bad behaviour in itself, but it is also an immediate feedback to the user, that the system is not responsive. The user cannot even reach a button to click it, before he sees that something is going on. In a bad situation, I think this is the less evil choice. I totally agree that when the GUI is totally stalled, the curser better be stalled as well... But this is actually a rather untypical case. Much more often the cursor just becomes somewhat jerky under load. The GUI becomes sluggish, but still quite usable. The jerky cursor however makes it much harder to work with it -- a smooth cursor indeed improves usability in this case. On top of that, there is an important psychological effect: With a jerky cursor, the system *feels* much slower than it actually is. Users think, This X stuff is reall crap: OS X/Windows/whatever is so much smoother... Sad but true. So ideally, the cursor should remain smooth under some load, but stall when the system is really busy... Any suggestions how to achieve that? :-) -antrik- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 0/4] Cursor's update inside kernel only
Hi, On Mon, Jan 05, 2009 at 06:55:50PM -0200, Tiago Vignatti wrote: Under KMS, we can build a feature to update the cursor directly to screen without the continuous intervention of the userspace application (X server, wayland, etc). It's a fastpath for DRM based cursors obtained by short-circuit the kernel input layer and DRM module. This would solve all cursor's latency issues that we have in our current model [0]. IHMO punting and pushing this into the kernel in totally the wrong approach. Following this method, you will end up running *everything* in kernel space. (Hi, DOS!) Rather, you should try to figure out *why* the update in user space has latencies not present when doing it in kernel space. Is it because all kernel memory is pinned? (Not true on all systems, BTW.) Is it because event delivery between kernel space and user space triggers bad CPU scheduling? Is it because the handling in user space is not properly prioritized? Once you know the real caus(es), you can go about fixing them -- adapting the design of the user space part, and possibly creating now kernel interfaces is necessary. Ultimately, the kernel/user space distinction is just an address space boundary. There is no fundamental reason why that should cause any latencies. -antrik- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Draft: License policy for contributors
Hi, On Wed, Dec 03, 2008 at 06:28:17AM +1100, Daniel Stone wrote: GFDL is out as DFSG-incompatible. I thought GFDL is fine DFSG-wise as long as there are no invariant sections/cover texts?... (Disclaimer: Not advocating GFDL use here; only pointing out.) -antrik- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: modular: Changes to 'master'
Hi, On Tue, Oct 21, 2008 at 09:51:45AM -0700, Keith Packard wrote: On Tue, 2008-10-21 at 18:15 +0200, Luc Verhaegen wrote: Is there a single technical reason why shipping both is a problem? For the same reason the kernel avoids shipping multiple drivers for the same hardware -- we want a unique PCI-ID - driver mapping so that all X.org downstream users share the same code base for their hardware. Forking driver development is a great way to explore new ideas and demonstrate new technologies, but in the long-term, we really want the best ideas to be integrated into a single driver for each device. Well, there might be some merit in only having a single driver for each piece of hardware (though I'm not entirely convinced of that) -- but on what grounds do you decide which one gets the preference? Dropping radeonhd looks like a totally arbitrary decision to me. After all, radeonhd has been added before radeon gained newer chipset support, and I really fail to see why radeon-now-with-r500+ should be treated as the official driver, and radeonhd as some alien... -antrik- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-radeonhd 1.2.2 Release
Hi, On Mon, Oct 13, 2008 at 08:03:43PM +0200, Matthias Hopf wrote: Version 1.2.2 improvements: - Added DRI support (R5xx and RS6xx). - Added support for RV770, RS780, M82, M86, and M88. - Added XVideo support. - Added CP based 2D acceleration (R5xx and RS6xx). - Added EXA render acceleration (R5xx and RS6xx). - Added support for AtomBIOS based mode setting. - Added support for scaled modes. - Added RandR support for backlight control. - Lots of modesetting related bug fixes. Considering the amount of non-bugfix changes, wouldn't 1.3 be actually much more appropriate naming?... -antrik- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Poll: Should Xorg change from using Ctrl+Alt+Backspace to something harder for users to press by accident?
Hi, On Tue, Sep 23, 2008 at 01:52:53PM +0930, Peter Hutterer wrote: driver kbd: hardcodes Ctrl + Alt + Backspace. (IMHO that's a bug anyway) driver evdev: the XKB map decides what happens. I don't know whether this is really related (I'm pretty sure I experienced that with kbd driver as well), but the fact that zap depends on xkb is actually quite problematic: When the xkb map is somehow borked, the server still starts, but it's not possible to zap (nor to switch console)... This gets really ugly when no other means to exit the server is available :-) -antrik- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Building X
Hi, On Mon, Sep 22, 2008 at 10:56:03AM -0400, Adam Jackson wrote: Right then. -br is now the default. -retro gives you the old school root window and cursor behavior. I don't understand why you don't leave the default as it was. Sureley the only situation where it is inconvenient to have to pass options explicitely, is when starting the server by hand for testing purposes -- and this is precisely the situation where both the weave and the cursor are useful... I see a bike shed and I want to paint it black... It's funny that you openly admit it's just a matter of taste, and yet seem set on changing the default for no good reason... Well, have fun dealing with all the bug reports from users wondering where the background/cursor has gone. -antrik- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
