where
heuristics are probably going to be involved.
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
take a look at libbacklight, which already has
some amount of support for appropriate heuristics.
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http
From: Matthew Garrett matthew.garr...@nebula.com
Users with devices that provide both a touchpad and an alternative input
device may not want to use the touchpad for pointer motion but may still
want to use it for gesture-based inputs. Add a configuration knob that
allows them to do so.
Signed
Users with devices that provide both a touchpad and an alternative input
device may not want to use the touchpad for pointer motion but may still
want to use it for gesture-based inputs. Add a configuration knob that
allows them to do so.
Signed-off-by: Matthew Garrett mj...@srcf.ucam.org
remains, assume a 14 svga fishbowl, and let
them edit their xorg.conf.
The common case for hitting this case now is that you have a projector
behind a display mux that doesn't do DDC. Most projectors are able to do
1024x768.
--
Matthew Garrett | mj...@srcf.ucam.org
On Thu, Nov 25, 2010 at 08:51:04PM +0100, Luc Verhaegen wrote:
On Thu, Nov 25, 2010 at 07:44:24PM +, Matthew Garrett wrote:
The common case for hitting this case now is that you have a projector
behind a display mux that doesn't do DDC. Most projectors are able to do
1024x768
is unnecessary. Our ISA support's somewhat lacking
these days, too.
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
On Thu, Nov 25, 2010 at 09:08:57PM +0100, Luc Verhaegen wrote:
On Thu, Nov 25, 2010 at 08:06:58PM +, Matthew Garrett wrote:
The absence of complaints about KMS exploding people's monitors implies
that nobody is actually running modern software on these displays, and
so catering
On Thu, Nov 25, 2010 at 09:17:26PM +0100, Luc Verhaegen wrote:
On Thu, Nov 25, 2010 at 08:14:36PM +, Matthew Garrett wrote:
We provide pretty much no support for hardware that's the same vintage
as the monitors you're talking about. Why would the people using these
monitors
On Thu, Nov 25, 2010 at 09:25:05PM +0100, Luc Verhaegen wrote:
On Thu, Nov 25, 2010 at 08:20:49PM +, Matthew Garrett wrote:
I think the benefit in supporting drivers for hardware that hasn't been
manufactured in 16 years is pretty minimal, but nobody's saying Don't
support old
On Thu, Nov 25, 2010 at 09:29:44PM +0100, Luc Verhaegen wrote:
On Thu, Nov 25, 2010 at 08:14:36PM +, Matthew Garrett wrote:
We provide pretty much no support for hardware that's the same vintage
as the monitors you're talking about. Why would the people using these
monitors
seem like a great plan (compare the code quality of nouveau, intel and
radeon to that of some of the out of tree drivers, for instance)
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org
involved in the kernel.
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
to determine whether a
mode is ok, and if they don't succeed then the mode is bad. Your problem
is that they're failing to pass for valid modes. Figure out why not and
you'll know how to fix this bug properly.
--
Matthew Garrett | mj...@srcf.ucam.org
to the current code. So no.
It is not equivalent.
The code will now always return MODE_OK and this function shouldn't be
modifying any of its parameters, so how is it not equivalent?
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg-devel
nasty if you use fork(2), which
the X server does.
Yeah, I expect that Amiga Unix has problems as well. Thankfully, this is
the 21st century.
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg-devel@lists.x.org: X.Org development
Archives: http
On Tue, Jul 27, 2010 at 08:23:05PM +0200, Mark Kettenis wrote:
How about fixing those bugs before killing it?
Because right now there's no incentive for anyone to fix those bugs
because they can use the vm86 backend instead?
--
Matthew Garrett | mj...@srcf.ucam.org
it, but it
is replacing one more platform-specific difference with common code.)
There's no fundamental reason for it to be, but I'll admit that I never
actually went to the extent of checking whether there was support code
for non-Linux.
--
Matthew Garrett | mj...@srcf.ucam.org
revoking the open file descriptors from one X
server when you switch to another. A compromised X server could keep
hold of them when you switch and obtain other users' passwords.
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg-devel@lists.x.org: X.Org
a sane thing to do in this case? Do I really
want to switch off the output?
If they want the internal display to be turned off when they're docked
then I suspect that they also want the geometry changed.
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg
On Mon, Feb 15, 2010 at 08:05:24PM -0500, Matt Turner wrote:
Signed-off-by: Matt Turner matts...@gmail.com
So while this won't break anything, are there actually any compilers
that we support which choke on this?
--
Matthew Garrett | mj...@srcf.ucam.org
, and it might be nice
to consolidate those before introducing further divergence. Other than
that, no objections.
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
. The server may want to
then expose it as a RANDR property.
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
panels, and, then what.
We just need to populate things appropriately. When the DRM layer is
handling things, there shouldn't be any ambiguity.
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org
to create multiple X input devices in a single
instance.
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
no problem with hosting GPLed code on freedesktop.org
in the general case. Personally I don't think there's any problem with
hosting GPLed xorg drivers under the xorg namespace, providing they're
not made part of the katamari releases.
--
Matthew Garrett | mj...@srcf.ucam.org
.
These tools are broken anyway. Users can remap the sequence via xkb.
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
On Sat, Mar 28, 2009 at 12:43:28PM -0400, Gerry Reno wrote:
Matthew Garrett wrote:
Tools that blindly assume something which may not be true are broken,
yes.
Under that theory then EVERYTHING is broken.
[citation needed]
--
Matthew Garrett | mj...@srcf.ucam.org
28 matches
Mail list logo
