Re: [PATCH 2/6] exa/mixed: be more thorough about setting fb_pitch when needed
On Wed, 2009-11-18 at 21:23 +0100, Maarten Maathuis wrote: Signed-off-by: Maarten Maathuis madman2...@gmail.com Acked-by: Michel Dänzer mic...@daenzer.net Actually, this seems to cause random crashes due to memory corruption here. Have you noticed anything like that Maarten? Might be best to revert this for now. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] EXA: Don't use UploadToScreen for CopyNtoN with mixed pixmaps.
From: Michel Dänzer daen...@vmware.com
Signed-off-by: Michel Dänzer daen...@vmware.com
---
exa/exa_accel.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index 7e2dd70..8e94df7 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -503,8 +503,13 @@ exaHWCopyNtoN (DrawablePtrpSrcDrawable,
(*pExaScr-info-DoneCopy) (pDstPixmap);
exaMarkSync (pDstDrawable-pScreen);
- /* UTS: mainly for SHM PutImage's secondary path. */
- } else {
+ /* UTS: mainly for SHM PutImage's secondary path.
+*
+* Not taking this path for mixed pixmaps: It could only save one CPU
+* copy between cached memory and risks causing a more expensive
+* DownloadFromScreen later on.
+*/
+ } else if (!pExaScr-info-flags EXA_MIXED_PIXMAPS) {
int bpp = pSrcDrawable-bitsPerPixel;
int src_stride = exaGetPixmapPitch(pSrcPixmap);
CARD8 *src = NULL;
@@ -531,7 +536,8 @@ exaHWCopyNtoN (DrawablePtrpSrcDrawable,
pbox++;
}
- }
+ } else
+ goto fallback;
} else
goto fallback;
--
1.6.4.3
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/2] I/O port access routines
On Wed, Nov 18, 2009 at 2:28 PM, Adam Jackson a...@redhat.com wrote: Signed-off-by: Adam Jackson a...@redhat.com --- include/pciaccess.h | 14 src/Makefile.am | 1 + src/common_io.c | 95 src/linux_sysfs.c | 184 -- src/pciaccess_private.h | 9 +++ 5 files changed, 263 insertions(+), 40 deletions(-) create mode 100644 src/common_io.c diff --git a/include/pciaccess.h b/include/pciaccess.h index 8128656..b4a431a 100644 --- a/include/pciaccess.h +++ b/include/pciaccess.h @@ -1,5 +1,6 @@ /* * (C) Copyright IBM Corporation 2006 + * Copyright 2009 Red Hat, Inc. * All Rights Reserved. * * Permission is hereby granted, free of charge, to any person obtaining a @@ -507,4 +508,17 @@ int pci_device_vgaarb_unlock (void); /* return the current device count + resource decodes for the device */ int pci_device_vgaarb_get_info (struct pci_device *dev, int *vga_count, int *rsrc_decodes); +/* + * I/O space access. + */ +void *pci_device_open_io(struct pci_device *dev, int bar); I'd make the returned void pointer a struct pci_device_io pointer instead. We don't have to actually define the struct anywhere, and it gives us typesafety and make the API more self-documenting. cheers, Kristian ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/2] I/O port access routines
On Thu, 2009-11-19 at 00:13 +0100, Mark Kettenis wrote:
From: Adam Jackson a...@redhat.com
Date: Wed, 18 Nov 2009 14:28:57 -0500
Signed-off-by: Adam Jackson a...@redhat.com
---
include/pciaccess.h | 14
src/Makefile.am |1 +
src/common_io.c | 95
src/linux_sysfs.c | 184
--
src/pciaccess_private.h |9 +++
5 files changed, 263 insertions(+), 40 deletions(-)
create mode 100644 src/common_io.c
Oh, you actually went ahead and implemented this. Cool!
I feel a bit guilty now, but I do have a few comments. I think the
interface to open io should actually allow one to specify a range,
much in the same way as pci_device_map_range() does. Perhaps the
right way to do this is simply to make pci_device_map_range() accept a
PCI_DEV_MAP_FLAG_IO flag. You'd still need to use the pci_io_xxx
functions on the returned address to handle x86 machines properly of
course.
I admit I was seduced by the ability to make the I/O handle just the
file descriptor. When I first started typing, the prototype read:
void *pci_legacy_open_io(struct pci_device *dev, uint16_t base, uint16_t
range);
Mostly for the reasons I'd said before, legacy port I/O should
reasonably prevent you from poking at config space registers and ports
claimed by BARs. But the asymmetry with pci_device_open_io() made the
in/out routines ambiguous. To what would their port argument refer?
The address in the domain, or the offset from the handle's base?
Implementing either one would require carrying around more state in the
region handle.
The other way to fix the asymmetry would have been to extend
pci_device_open_io() to also take a base/range pair. But I was
hard-pressed to come up with a use case where they would ever not be the
whole BAR. pci_device_map_range() makes sense because sometimes you
need different caching policies on different bits of the BAR, but I/O
(thankfully) never got posting policy control.
So then I thought about the implications of keeping base/range for
legacy I/O. The major user I have in mind is libx86, where you need the
entire legacy range opened because the VBIOS you're executing might in
fact touch _any_ I/O port, and there's no real way of predicting that a
priori. So if the pci_io routines refused to let you touch some ports,
libx86 would have to create multiple legacy I/O handles around them in
all the negative space, and then walk its own internal map from
base/range to handle. That seems like it creates work rather than
solves problems. Especially if the blacklist in libpciaccess changed
over time.
So dropping ranges from the open routines seemed attractively simple.
It makes the port arguments unambiguous (the offset from the handle's
base), it matches the known use cases, and it means the handle can be
just the naked file descriptor. I could probably be talked into putting
ranges back in, but if we do so I don't think the legacy API should
prevent you from shooting yourself in the foot.
I should add some internal bookkeeping anyway though, because
pci_system_cleanup() will not close I/O handles. Oops.
Regarding those pci_io_xxx functions, would it be better to encode the
access size a bit more explicit, like the config space access functions?
pci_io_read_u8()
pci_io_read_u16()
pci_io_read_u32()
pci_io_write_u8()
pci_io_write_u16()
pci_io_write_u32()
The 'b' in inb/outb is unambiguous, but the 'w' and the 'l' already
didn't make sense for 32-bit machines, let alone now that we have
64-bit machines.
I don't feel strongly either way. It's not ambiguous if you remember
that the 8086 instructions were {in,out}{b,w,l} and 8086 compatibility
is the whole point of the I/O space, but, not needing to remember 8086
arcana is the whole reason we have abstraction layers in the first
place.
- ajax
signature.asc
Description: This is a digitally signed message part
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: New development model check-in.
On Thu, 2009-11-19 at 01:41 +1100, Daniel Stone wrote:
On Wed, Nov 18, 2009 at 02:48:45PM +0100, Luc Verhaegen wrote:
On Thu, Nov 19, 2009 at 12:30:53AM +1100, Daniel Stone wrote:
I don't think that's necessarily true in areas that aren't EXA;
certainly, no-one else has complained, and the patch flow from both
regular and one-off contributors seems to be very similar to what it was
before the change.
I can't speak for Keith, but I would've assumed that as a major
subsystem responsible for some inordinately large percentage of commits
these days, that EXA would have (at least) one tree where one could pull
from to obtain the latest reviewed and mergeable EXA commits. It makes
everyone's lives a lot easier -- including yours, because you don't have
to patchbomb the list and follow up doggedly on the patchbombs. One
mail ('please pull the EXA tree') would suffice.
So if this mode of working is now imposed, does that mean that our ~ on
annarchy, which will supposedly hold such trees, will be backed up now?
Right now, it's not, but someone proposed backing up at least the git
trees, which I think makes a great deal of sense.
I'd be pretty concerned if a git tree for a major component like EXA
vanished with no-one at all having any kind of copy of it though;
wouldn't you?
In the last data loss, my ~anholt/mesa disappeared. I figured I'd
re-upload it at some point, but there are a bunch of branches to put up,
so I put it off. Some people wanted some of it, but meh. Yesterday, in
the midst of some travel-related sleep-dep I nearly hosed my Mesa git
tree, and realized that my backup of my Mesa tree (annarchy) wasn't
backed up at the moment, and I could have lost everything.
Yeah, my laptop should be backed up. But could we please backup
annarchy for imperfect people?
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/2] I/O port access routines
On Thu, Nov 19, 2009 at 01:45:57AM +0100, ext Luc Verhaegen wrote: But the main point of this mail was ignored. Why did existing xorg pci infrastructure have to be reinvented like that instead of adding a new backend and fixing up the bad patches? Why did RAC get thrown away like that? Why does this NIH have to keep on repeating itself? The main reason is because we were needing a PCI resource broker for the entire system and not for one process only. And X was touching the PCI resources directly with RAC.. oops! We don't need and our 21st century's kernels do it pretty well for us :) Tiago ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/2] I/O port access routines
On Thu, Nov 19, 2009 at 06:06:47PM +0200, Tiago Vignatti wrote: On Thu, Nov 19, 2009 at 01:45:57AM +0100, ext Luc Verhaegen wrote: But the main point of this mail was ignored. Why did existing xorg pci infrastructure have to be reinvented like that instead of adding a new backend and fixing up the bad patches? Why did RAC get thrown away like that? Why does this NIH have to keep on repeating itself? The main reason is because we were needing a PCI resource broker for the entire system and not for one process only. And X was touching the PCI resources directly with RAC.. oops! We don't need and our 21st century's kernels do it pretty well for us :) Tiago You're talking RAC backend here. Once the RAC was initialised to know what resources this hardware needed, it handled everything for the driver without having to care for anything. This for memory, io and vga (a subclass of io). What i see now is that _everything_ got reinvented, instead of having written up a backend for a modern operating system, and maybe adjusting initialisation on the driver level (as part of this info really can be retrieved from the os now). Re-inventing everything is exactly the criticism that libpciaccess got, apart from it having not been tested on any worthwhile subset of hardware. Yet people still seem unable or unwilling to learn from their mistakes. Luc Verhaegen. ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/2] I/O port access routines
On Thu, Nov 19, 2009 at 05:20:41PM +0100, Luc Verhaegen wrote: On Thu, Nov 19, 2009 at 06:06:47PM +0200, Tiago Vignatti wrote: On Thu, Nov 19, 2009 at 01:45:57AM +0100, ext Luc Verhaegen wrote: But the main point of this mail was ignored. Why did existing xorg pci infrastructure have to be reinvented like that instead of adding a new backend and fixing up the bad patches? Why did RAC get thrown away like that? Why does this NIH have to keep on repeating itself? The main reason is because we were needing a PCI resource broker for the entire system and not for one process only. And X was touching the PCI resources directly with RAC.. oops! We don't need and our 21st century's kernels do it pretty well for us :) You're talking RAC backend here. Once the RAC was initialised to know what resources this hardware needed, it handled everything for the driver without having to care for anything. This for memory, io and vga (a subclass of io). What i see now is that _everything_ got reinvented, instead of having written up a backend for a modern operating system, and maybe adjusting initialisation on the driver level (as part of this info really can be retrieved from the os now). Re-inventing everything is exactly the criticism that libpciaccess got, apart from it having not been tested on any worthwhile subset of hardware. Yet people still seem unable or unwilling to learn from their mistakes. PCI code was removed (well, it's being) from X and needed be put somewhere. libpciaccess was the name of the place. I can imagine how tied and coupled such code was with the rest of the server and it was more easy to just reimplement some parts. So, it was a decision that someone made. But the removal of PCI from X was not all the problem; there was also RAC which, as I said to you, should be visible from other apps. Given, recently kernels are already doing a lot of RAC's job, we decided to just call another name - VGA arbiter - and implement only the necessary parts. I don't see why you're complaining so much... Tiago ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/2] I/O port access routines
On Thu, 2009-11-19 at 00:37 +0100, Luc Verhaegen wrote:
And i just keep on wondering... Just like with the VGA arbitration...
Didn't the RAC used wrap all this crap for us _outside_ calls to driver
code so that we could just access IO and memory directly, without
having to care at all?
RAC did not handle this correctly when multiple X servers were running;
VGA arb does. The I/O port routines in the server - not strictly part
of RAC - leave the onus of domain safety on the driver, and are a
wretched pile of ifdef (though admittedly a working pile).
The deeper assumption with RAC was that the OS could not be trusted to
give you a working PCI memory map, and that it was okay to rewrite it.
No no no no no.
How hard would it have been to have written up a
backend for the RAC for the linux pci code that popped up during the
active life of RAC? My guess is, much easier than the stuff that has to
be pulled now, all it took was that someone was willing to go into
existing code and understand how it work(s/ed).
The Linux PCI code did use RAC. I don't know why you think it didn't?
As someone who's actually had to fix bugs in the PCI code in 6.8:
while:
- the transition to the new library was ungraceful
- the motivation for switching was a complete MacGuffin
- the internal conversion to pciaccess is still incomplete, and
- the completion of VGA arbitration took embarassingly long
I can honestly and without reservation say that the current code is
comprehensible and pleasant to work with, and the old PCI layer has
literally woken me from sleep sweating in terror.
Oh, and that's before i start wondering about gratuitous void pointers
and goto.
The handle needs to be opaque to the user, because it's intrinsically
platform-dependent. Kristian's opaque struct name suggestion is
probably what I'll go with.
In this particular case, yeah, the goto should reasonably be thus:
/* First check if there's a legacy io method for the device */
while (dev) {
snprintf(name, PATH_MAX, /sys/class/pci_bus/%04x:%02x/legacy_io,
dev-domain, dev-bus);
ret = open(name, O_RDWR);
if (ret = 0)
break;
dev = pci_device_get_parent_bridge(dev);
}
/* If not, /dev/port is the best we can do */
if (!dev)
ret = open(/dev/port, O_RDWR);
if (ret == 0) {
int new = dup(ret);
close(ret);
ret = new;
}
- ajax
signature.asc
Description: This is a digitally signed message part
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/2] I/O port access routines
On Thu, Nov 19, 2009 at 11:53:16AM -0500, Adam Jackson wrote: On Thu, 2009-11-19 at 00:37 +0100, Luc Verhaegen wrote: And i just keep on wondering... Just like with the VGA arbitration... Didn't the RAC used wrap all this crap for us _outside_ calls to driver code so that we could just access IO and memory directly, without having to care at all? RAC did not handle this correctly when multiple X servers were running; VGA arb does. The I/O port routines in the server - not strictly part of RAC - leave the onus of domain safety on the driver, and are a wretched pile of ifdef (though admittedly a working pile). The deeper assumption with RAC was that the OS could not be trusted to give you a working PCI memory map, and that it was okay to rewrite it. No no no no no. This was not just RAC, this was just the situation of that time. Now, my understanding of RAC, from a driver point of view, was that you provided it with some information as to what resources your hardware needed, and it would then magically take care of everything for you, before you entered any driver specific call, so you never had to worry about it then. Afaik, instead of fixing up the backend, this nice infrastructure was entirely removed. Because this is really what i care about, as long as it is all behind the scenes, and it has no consequences for me as a driver developer, and it works (without making the mistakes that old solutions fixed), i am happy. Look at this code, it is so close to RAC like behaviour already. There is code to enable and disable io access. Why can we not use IN/OUT[BWL] macros in between like before? Why can enable/disable not wrap driver calls like RAC before? The baby was thrown out with the bathwater with libpciaccess and vga arbitration, and now suddenly the plan seems to be to put these new enable/disable hooks all over the driver, together with slightly more involved IN/OUT calls. Unacceptable. How hard would it have been to have written up a backend for the RAC for the linux pci code that popped up during the active life of RAC? My guess is, much easier than the stuff that has to be pulled now, all it took was that someone was willing to go into existing code and understand how it work(s/ed). The Linux PCI code did use RAC. I don't know why you think it didn't? As someone who's actually had to fix bugs in the PCI code in 6.8: while: - the transition to the new library was ungraceful - the motivation for switching was a complete MacGuffin - the internal conversion to pciaccess is still incomplete, and - the completion of VGA arbitration took embarassingly long I can honestly and without reservation say that the current code is comprehensible and pleasant to work with, and the old PCI layer has literally woken me from sleep sweating in terror. Of course it is, today we can depend on operating systems have useful pci support. Not so then. But there is nothing that stopped people from keeping the upper level infrastructure in place while having reworked the backend to work on top of the now existing nice pci support in the kernel. The only reason to replace the whole thing was rampant NIH. And this rampant NIH is the core cause for the big nasty interface change and RAC being #ifdeffed and commented out, without a replacement, for several years. Oh, and that's before i start wondering about gratuitous void pointers and goto. The handle needs to be opaque to the user, because it's intrinsically platform-dependent. Kristian's opaque struct name suggestion is probably what I'll go with. Ah, good, typechecking will still happen then. Thanks. Luc Verhaegen. ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/2] I/O port access routines
On Thu, Nov 19, 2009 at 06:36:15PM +0200, Tiago Vignatti wrote: PCI code was removed (well, it's being) from X and needed be put somewhere. libpciaccess was the name of the place. I can imagine how tied and coupled such code was with the rest of the server and it was more easy to just reimplement some parts. So, it was a decision that someone made. But the removal of PCI from X was not all the problem; there was also RAC which, as I said to you, should be visible from other apps. Given, recently kernels are already doing a lot of RAC's job, we decided to just call another name - VGA arbiter - and implement only the necessary parts. I don't see why you're complaining so much... Tiago Oh man... This whole logic, when looked at it by a driver developer who just wants to have his driver work, is soo interdependent. Current situation: * We have to wrap io calls in the driver. * Why? * Because we threw out RAC completely. * Why? * Because we no longer had VGA arbitration. * Why? * Because we daftly threw out the old xserver pci code completely and reinvented it, and didn't bother to keep existing APIs nor give RAC support for this new backend code. * Why did we throw out old pci code? * Because the lowlevel code was involved and was not using the operating system infrastructure that popped up recently. * Why do it that way? * Because it's just how we did it, ok? now stfu. Now i am sure that i am not the only person who frowns upon the logic applied in there, when it is, finally, laid out like this. And Tiago, it was not coupled that tightly. It supported just about every operating system out there at the time (in as far as it supported operating systems itself), and the driver side interface was not fundamentally different from what we have now. For reference, you can go and check any driver that has the compat code. Code is mostly different for the sake of being different. NIH. Luc Verhaegen. ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/2] I/O port access routines
On Thu, Nov 19, 2009 at 06:36:12PM +0100, Luc Verhaegen wrote: And Tiago, it was not coupled that tightly. Well, just look at the head of xf86pciBus.c (before RAC be removed and when the old PCI code was in place): #ifdef HAVE_XORG_CONFIG_H #include xorg-config.h #endif #include ctype.h #include stdlib.h #include unistd.h #include X11/X.h #include os.h #include Pci.h #include xf86.h #include xf86Priv.h #include xf86Resources.h /* Bus-specific headers */ #include xf86PciData.h #include xf86Bus.h #define XF86_OS_PRIVS #define NEED_OS_RAC_PROTOS #include xf86_OSproc.h #include xf86RAC.h It was mix of RAC + PCI + BUS + high level screen informations + X protocol + real-mode things and etc, and you're saying that that code was not coupled? So I _really_ don't know what you mean about tightly, coupled and confusing code... Tiago ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/2] I/O port access routines
From: Adam Jackson a...@redhat.com Date: Thu, 19 Nov 2009 13:58:52 -0500 On Thu, 2009-11-19 at 18:25 +0100, Luc Verhaegen wrote: The baby was thrown out with the bathwater with libpciaccess and vga arbitration, and now suddenly the plan seems to be to put these new enable/disable hooks all over the driver, together with slightly more involved IN/OUT calls. The enable/disable thing, no. That wrapping is in the server. You don't have to do it from your driver. You seem to be putting words in my mouth with the in/out stuff though. I haven't actually said anything (yet) about whether the drivers may continue to use the old in/out calls. All I've done here is add API to the hardware access library to let me get at the third of the three address spaces the hardware exposes. While I'm sympathetic too many of the things Luc is saying, Adam is right here. The new interfaces will allow you to access PCI I/O BARs (and only that particular I/O BAR) and do so in a way that also works right for machines that have multiple PCI domains. That is something the old code simply didn't support. This patch is (almost) exactly the functionality I need to make the i128 driver work on OpenBSD/sparc64. ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/2] I/O port access routines
From: Adam Jackson a...@redhat.com
Date: Thu, 19 Nov 2009 10:23:49 -0500
On Thu, 2009-11-19 at 00:13 +0100, Mark Kettenis wrote:
From: Adam Jackson a...@redhat.com
Date: Wed, 18 Nov 2009 14:28:57 -0500
Signed-off-by: Adam Jackson a...@redhat.com
---
include/pciaccess.h | 14
src/Makefile.am |1 +
src/common_io.c | 95
src/linux_sysfs.c | 184
--
src/pciaccess_private.h |9 +++
5 files changed, 263 insertions(+), 40 deletions(-)
create mode 100644 src/common_io.c
Oh, you actually went ahead and implemented this. Cool!
I feel a bit guilty now, but I do have a few comments. I think the
interface to open io should actually allow one to specify a range,
much in the same way as pci_device_map_range() does. Perhaps the
right way to do this is simply to make pci_device_map_range() accept a
PCI_DEV_MAP_FLAG_IO flag. You'd still need to use the pci_io_xxx
functions on the returned address to handle x86 machines properly of
course.
I admit I was seduced by the ability to make the I/O handle just the
file descriptor. When I first started typing, the prototype read:
void *pci_legacy_open_io(struct pci_device *dev, uint16_t base, uint16_t
range);
uint16_t? PCI provides a ful 32-bit address space for I/O space.
Probably quite a bit of hardware out there that doesn't really support
that, but still...
Mostly for the reasons I'd said before, legacy port I/O should
reasonably prevent you from poking at config space registers and ports
claimed by BARs. But the asymmetry with pci_device_open_io() made the
in/out routines ambiguous. To what would their port argument refer?
The address in the domain, or the offset from the handle's base?
Implementing either one would require carrying around more state in the
region handle.
Not sure I understand completely what you're saying here. However you
are asking the right question. I'd say the answer is obvious: the
port argument to the in/out routines should be the offset relative
to base of the handle.
The other way to fix the asymmetry would have been to extend
pci_device_open_io() to also take a base/range pair. But I was
hard-pressed to come up with a use case where they would ever not be the
whole BAR. pci_device_map_range() makes sense because sometimes you
need different caching policies on different bits of the BAR, but I/O
(thankfully) never got posting policy control.
Well, I do think it would be superior. For one thing, BAR numbering
is ambiguous in the presence of 64-bit BARs. Also, there are devices
where certain register blocks are moved around between different
generations of a device. In that case you could either specify the
right offset when you map things, or specify an offset for every
in/out call. Guess what I'd prefer.
So then I thought about the implications of keeping base/range for
legacy I/O. The major user I have in mind is libx86, where you need the
entire legacy range opened because the VBIOS you're executing might in
fact touch _any_ I/O port, and there's no real way of predicting that a
priori. So if the pci_io routines refused to let you touch some ports,
libx86 would have to create multiple legacy I/O handles around them in
all the negative space, and then walk its own internal map from
base/range to handle. That seems like it creates work rather than
solves problems. Especially if the blacklist in libpciaccess changed
over time.
Ah, well, I'm thinking about the drivers proper that will be mapping
(parts) of an I/O BAR. And, I don't see your problem here. The
kernel should enforce restrictions, not libpciaccess.
Regarding those pci_io_xxx functions, would it be better to encode the
access size a bit more explicit, like the config space access functions?
pci_io_read_u8()
pci_io_read_u16()
pci_io_read_u32()
pci_io_write_u8()
pci_io_write_u16()
pci_io_write_u32()
The 'b' in inb/outb is unambiguous, but the 'w' and the 'l' already
didn't make sense for 32-bit machines, let alone now that we have
64-bit machines.
I don't feel strongly either way. It's not ambiguous if you remember
that the 8086 instructions were {in,out}{b,w,l} and 8086 compatibility
is the whole point of the I/O space, but, not needing to remember 8086
arcana is the whole reason we have abstraction layers in the first
place.
Exactly!
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: xf86-video-nv: 5 commits - compat/.gitignore configure.ac .gitignore Makefile.am man/.gitignore
This causes a significant amount of breakage. ChangeLog is now no longer
cleaned by any of the automake clean commands, including maintainer-clean.
Also, it causes dist to fail when --prefix was not specified:
$ make dist
(GIT_DIR=./.git git log ./.changelog.tmp mv ./.changelog.tmp ./ChangeLog)
|| (rm -f ./.changelog.tmp; touch ./ChangeLog; echo 'git directory not found:
installing possibly empty changelog.' 2)
if test -f NONE/share/doc/util-macros/INSTALL; then cp -f
NONE/share/doc/util-macros/INSTALL .; else echo
'NONE/share/doc/util-macros/INSTALL cannot be found.' 2; fi
NONE/share/doc/util-macros/INSTALL cannot be found.
{ test ! -d xf86-video-nv-2.1.15 || { find xf86-video-nv-2.1.15 -type d !
-perm -200 -exec chmod u+w {} ';' rm -fr xf86-video-nv-2.1.15; }; }
test -d xf86-video-nv-2.1.15 || mkdir xf86-video-nv-2.1.15
cp: cannot stat `./INSTALL': No such file or directory
make: *** [distdir] Error 1
-- Aaron
On Thu, Nov 19, 2009 at 11:39:56AM -0800, Gaetan Nadon wrote:
.gitignore| 75
++
Makefile.am | 11 ---
compat/.gitignore |1
configure.ac | 14 --
man/.gitignore|2 -
5 files changed, 78 insertions(+), 25 deletions(-)
New commits:
commit 8664df401ff26718608e0bfc319514387d232771
Author: Gaetan Nadon mems...@videotron.ca
Date: Wed Oct 28 14:41:41 2009 -0400
INSTALL, NEWS, README or AUTHORS files are missing/incorrect #24206
Automake 'foreign' option is specified in configure.ac.
Remove from Makefile.am
diff --git a/Makefile.am b/Makefile.am
index 9053bb4..0eb97b1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -18,7 +18,6 @@
# IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
-AUTOMAKE_OPTIONS = foreign
SUBDIRS = src man compat
EXTRA_DIST = README.G80
commit bbb016dfdca06c34bdc163ee772284a5fc1f1139
Author: Gaetan Nadon mems...@videotron.ca
Date: Wed Oct 28 14:09:09 2009 -0400
INSTALL, NEWS, README or AUTHORS files are missing/incorrect #24206
Add missing INSTALL file. Use standard GNU file on building tarball
README may have been updated
Remove AUTHORS file as it is empty and no content available yet.
Remove NEWS file as it is empty and no content available yet.
diff --git a/Makefile.am b/Makefile.am
index 3c6c5e7..9053bb4 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -23,9 +23,12 @@ SUBDIRS = src man compat
EXTRA_DIST = README.G80
-.PHONY: ChangeLog
+.PHONY: ChangeLog INSTALL
+
+INSTALL:
+ $(INSTALL_CMD)
ChangeLog:
$(CHANGELOG_CMD)
-dist-hook: ChangeLog
+dist-hook: ChangeLog INSTALL
diff --git a/configure.ac b/configure.ac
index 6d53025..1947f4d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -37,7 +37,7 @@ XORG_DEFAULT_OPTIONS
AC_CONFIG_AUX_DIR(.)
-AM_INIT_AUTOMAKE([dist-bzip2])
+AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
commit ee24fd1773268e0a593c7de760bafa282f3489a2
Author: Gaetan Nadon mems...@videotron.ca
Date: Mon Oct 26 12:54:21 2009 -0400
Several driver modules do not have a ChangeLog target in Makefile.am
#23814
The git generated ChangeLog replaces the hand written one.
Update configure.ac to xorg-macros level 1.3.
Use XORG_DEFAULT_OPTIONS which replaces four XORG_* macros
Update Makefile.am to add ChangeLog target if missing
Remove ChangeLog from EXTRA_DIST or *CLEAN variables
This is a pre-req for the INSTALL_CMD
diff --git a/Makefile.am b/Makefile.am
index 0891338..3c6c5e7 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -21,9 +21,8 @@
AUTOMAKE_OPTIONS = foreign
SUBDIRS = src man compat
-EXTRA_DIST = README.G80 ChangeLog
+EXTRA_DIST = README.G80
-CLEANFILES = ChangeLog
.PHONY: ChangeLog
ChangeLog:
diff --git a/configure.ac b/configure.ac
index ce0b884..6d53025 100644
--- a/configure.ac
+++ b/configure.ac
@@ -29,9 +29,11 @@ AC_INIT([xf86-video-nv],
AC_CONFIG_SRCDIR([Makefile.am])
AM_CONFIG_HEADER([config.h])
-# Require xorg-macros: XORG_RELEASE_VERSION XORG_CHANGELOG
-m4_ifndef([XORG_MACROS_VERSION], [AC_FATAL([must install xorg-macros 1.2 or
later before running autoconf/autogen])])
-XORG_MACROS_VERSION(1.2)
+# Require xorg-macros: XORG_DEFAULT_OPTIONS
+m4_ifndef([XORG_MACROS_VERSION],
+ [m4_fatal([must install xorg-macros 1.3 or later before running
autoconf/autogen])])
+XORG_MACROS_VERSION(1.3)
+XORG_DEFAULT_OPTIONS
AC_CONFIG_AUX_DIR(.)
@@ -136,10 +138,6 @@ AC_SUBST([moduledir])
DRIVER_NAME=nv
AC_SUBST([DRIVER_NAME])
-XORG_MANPAGE_SECTIONS
-XORG_RELEASE_VERSION
-XORG_CHANGELOG
-
AC_OUTPUT([
Makefile
src/Makefile
commit 57c505852bcf38dc3a3e6a9d603e4a8fd9ed3b80
Author: Gaetan Nadon mems...@videotron.ca
Date: Thu Oct 22 13:02:49 2009 -0400
[PATCH:util/modular] release.sh: use the remote consistently.
Don't just use the specified remote for the git push, also check on the remote for the tag names, etc. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- release.sh |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/release.sh b/release.sh index a2f5b0b..d7b88da 100755 --- a/release.sh +++ b/release.sh @@ -138,7 +138,7 @@ fi # Check if the object has been pushed. Do do so # 1. Check if the current branch has the object. If not, abort. -# 2. Check if the object is on origin/branchname. If not, abort. +# 2. Check if the object is on $remote/branchname. If not, abort. local_sha=`git rev-list -1 $tag_current` current_branch=`git branch | grep \* | sed -e s/\* //` set +e @@ -149,12 +149,12 @@ if [ $? -eq 1 ]; then exit 1 fi -revs=`git rev-list origin/$current_branch..$current_branch | wc -l` +revs=`git rev-list $remote/$current_branch..$current_branch | wc -l` if [ $revs -ne 0 ]; then -git rev-list origin/$current_branch..$current_branch | grep $local_sha /dev/null +git rev-list $remote/$current_branch..$current_branch | grep $local_sha /dev/null if [ $? -ne 1 ]; then -echo origin/$current_branch doesn't have object $local_sha +echo $remote/$current_branch doesn't have object $local_sha echo for tag '$tag_current'. Did you push branch first? Aborting. exit 1 fi -- 1.6.5.2 ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH:util/modular] release.sh: use the remote consistently.
Reviewed-by: Jeremy Huddleston jerem...@apple.com On Nov 19, 2009, at 16:14, Peter Hutterer wrote: Don't just use the specified remote for the git push, also check on the remote for the tag names, etc. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- release.sh |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/release.sh b/release.sh index a2f5b0b..d7b88da 100755 --- a/release.sh +++ b/release.sh @@ -138,7 +138,7 @@ fi # Check if the object has been pushed. Do do so # 1. Check if the current branch has the object. If not, abort. -# 2. Check if the object is on origin/branchname. If not, abort. +# 2. Check if the object is on $remote/branchname. If not, abort. local_sha=`git rev-list -1 $tag_current` current_branch=`git branch | grep \* | sed -e s/\* //` set +e @@ -149,12 +149,12 @@ if [ $? -eq 1 ]; then exit 1 fi -revs=`git rev-list origin/$current_branch..$current_branch | wc -l` +revs=`git rev-list $remote/$current_branch..$current_branch | wc -l` if [ $revs -ne 0 ]; then -git rev-list origin/$current_branch..$current_branch | grep $local_sha /dev/null +git rev-list $remote/$current_branch..$current_branch | grep $local_sha /dev/null if [ $? -ne 1 ]; then -echo origin/$current_branch doesn't have object $local_sha +echo $remote/$current_branch doesn't have object $local_sha echo for tag '$tag_current'. Did you push branch first? Aborting. exit 1 fi -- 1.6.5.2 ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel smime.p7s Description: S/MIME cryptographic signature ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: xf86-video-nv: 5 commits - compat/.gitignore configure.ac .gitignore Makefile.am man/.gitignore
On Thu, 2009-11-19 at 16:34 -0800, Aaron Plattner wrote:
On Thu, Nov 19, 2009 at 04:28:24PM -0800, Gaetan Nadon wrote:
On Thu, 2009-11-19 at 15:34 -0800, Aaron Plattner wrote:
This causes a significant amount of breakage. ChangeLog is now no longer
cleaned by any of the automake clean commands, including maintainer-clean.
Also, it causes dist to fail when --prefix was not specified:
I'll look into this right away, starting with the most urgent issue, make
dist. The command copies the INSTALL file from the document directory,
$(prefix)/share/doc/util-macros. What looks suspicious is the
NONE/share/doc/util-macros. Is NONE a real directory? You can contact me
directly.
No, I just didn't specify it on the command line. The fundamental problem
is that it's trying to use the package's --prefix to find the INSTALL file
from util-macros, which may have been installed at a different prefix:
$ ./configure --prefix=/no-such-directory
checking for gcc... gcc
checking for C compiler default output file name... a.out
[..etc..]
$ make dist
(GIT_DIR=./.git git log ./.changelog.tmp mv ./.changelog.tmp
./ChangeLog) || (rm -f ./.changelog.tmp; touch ./ChangeLog; echo 'git
directory not found: installing possibly empty changelog.' 2)
if test -f /no-such-directory/share/doc/util-macros/INSTALL; then cp -f
/no-such-directory/share/doc/util-macros/INSTALL .; else echo
'/no-such-directory/share/doc/util-macros/INSTALL cannot be found.' 2; fi
/no-such-directory/share/doc/util-macros/INSTALL cannot be found.
{ test ! -d xf86-video-nv-2.1.15 || { find xf86-video-nv-2.1.15 -type d !
-perm -200 -exec chmod u+w {} ';' rm -fr xf86-video-nv-2.1.15; }; }
test -d xf86-video-nv-2.1.15 || mkdir xf86-video-nv-2.1.15
cp: cannot stat `./INSTALL': No such file or directory
make: *** [distdir] Error 1
Note that it's trying to copy from
/no-such-directory/share/doc/util-macros/INSTALL even though util-macros
was installed with --prefix=/usr.
You're right, there was a hidden assumption that the prefix of
util-macros was known. I don't think there is a reliable way of finding
this information. This was an attempt to save from having to check-in
250 INSTALL file. A large number of modules did not have any. It looks
like this is the only alternative now.
To recover, the target from Makefile.am can be removed. As long as the
INSTALL file is present in the root directory, it will be included in
the tarball by Automake. Just for completeness, note that .gitignore has
an entry to ignore INSTALL as it was intended to be generated.
It is true that ChangeLog, INSTALL NEWS, AUTHORS and some other files
cannot be deleted. This is a designed behaviour by autoconf/automake. I
have seen on the net not everyone agrees with that.
Would you like me to create a patch right now?
Peter: Note that, like ChangeLog, INSTALL is also not cleaned by anything
short of a git clean -xf so you probably have one laying around from
earlier.
-- Aaron
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: New development model check-in.
On Thu, 19 Nov 2009 18:18:45 +0200, Tiago Vignatti tiago.vigna...@nokia.com wrote: Yeah, I lost my implementation of the X server with the separate thread for input stuffs. Would be nice to have it for future references or whatever. So let's please backup annarchy! Ok, I'll go ask our (free) hosting provider and see if they're able to do this, and if not, I'll go find money to buy our own backup system. -- keith.pack...@intel.com pgp93N3Jhzyw0.pgp Description: PGP signature ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: xf86-video-nv: 5 commits - compat/.gitignore configure.ac .gitignore Makefile.am man/.gitignore
On Thu, Nov 19, 2009 at 05:09:59PM -0800, Gaetan Nadon wrote:
On Thu, 2009-11-19 at 16:34 -0800, Aaron Plattner wrote:
On Thu, Nov 19, 2009 at 04:28:24PM -0800, Gaetan Nadon wrote:
On Thu, 2009-11-19 at 15:34 -0800, Aaron Plattner wrote:
This causes a significant amount of breakage. ChangeLog is now no longer
cleaned by any of the automake clean commands, including maintainer-clean.
Also, it causes dist to fail when --prefix was not specified:
I'll look into this right away, starting with the most urgent issue, make
dist. The command copies the INSTALL file from the document directory,
$(prefix)/share/doc/util-macros. What looks suspicious is the
NONE/share/doc/util-macros. Is NONE a real directory? You can contact me
directly.
No, I just didn't specify it on the command line. The fundamental problem
is that it's trying to use the package's --prefix to find the INSTALL file
from util-macros, which may have been installed at a different prefix:
$ ./configure --prefix=/no-such-directory
checking for gcc... gcc
checking for C compiler default output file name... a.out
[..etc..]
$ make dist
(GIT_DIR=./.git git log ./.changelog.tmp mv ./.changelog.tmp
./ChangeLog) || (rm -f ./.changelog.tmp; touch ./ChangeLog; echo 'git
directory not found: installing possibly empty changelog.' 2)
if test -f /no-such-directory/share/doc/util-macros/INSTALL; then cp -f
/no-such-directory/share/doc/util-macros/INSTALL .; else echo
'/no-such-directory/share/doc/util-macros/INSTALL cannot be found.' 2; fi
/no-such-directory/share/doc/util-macros/INSTALL cannot be found.
{ test ! -d xf86-video-nv-2.1.15 || { find xf86-video-nv-2.1.15 -type d !
-perm -200 -exec chmod u+w {} ';' rm -fr xf86-video-nv-2.1.15; }; }
test -d xf86-video-nv-2.1.15 || mkdir xf86-video-nv-2.1.15
cp: cannot stat `./INSTALL': No such file or directory
make: *** [distdir] Error 1
Note that it's trying to copy from
/no-such-directory/share/doc/util-macros/INSTALL even though util-macros
was installed with --prefix=/usr.
You're right, there was a hidden assumption that the prefix of
util-macros was known. I don't think there is a reliable way of finding
this information. This was an attempt to save from having to check-in 250
INSTALL file. A large number of modules did not have any. It looks like
this is the only alternative now.
To recover, the target from Makefile.am can be removed. As long as the
INSTALL file is present in the root directory, it will be included in the
tarball by Automake. Just for completeness, note that .gitignore has an
entry to ignore INSTALL as it was intended to be generated.
Just checking them in to each module sounds reasonable to me, but I'd be
interested to see what others think. I don't it's ultra-urgent that this
be fixed right away.
It is true that ChangeLog, INSTALL NEWS, AUTHORS and some other files
cannot be deleted. This is a designed behaviour by autoconf/automake. I
have seen on the net not everyone agrees with that.
If they're checked into the git repository, that sounds right. If they're
generated though, like ChangeLog is, then at least maintainer-clean (and
probably also clean or even mostlyclean) ought to clean it. The automake
documentation describes the clean rules this way:
• If make built it, and it is commonly something that one would want to
rebuild (for instance, a ‘.o’ file), then mostlyclean should delete it.
• Otherwise, if make built it, then clean should delete it.
• If configure built it, then distclean should delete it.
• If the maintainer built it (for instance, a ‘.info’ file), then
maintainer-clean should delete it. However maintainer-clean should not
delete anything that needs to exist in order to run ‘./configure
make’.
-- Aaron
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: xf86-video-nv: 5 commits - compat/.gitignore configure.ac .gitignore Makefile.am man/.gitignore
Aaron Plattner wrote: It is true that ChangeLog, INSTALL NEWS, AUTHORS and some other files cannot be deleted. This is a designed behaviour by autoconf/automake. I have seen on the net not everyone agrees with that. If they're checked into the git repository, that sounds right. If they're generated though, like ChangeLog is, then at least maintainer-clean (and probably also clean or even mostlyclean) ought to clean it. The automake documentation describes the clean rules this way: clean should not, since there's no way for a tarball user to get it back. maintainer-clean should, which is what was previously done, since that will only be active for people building from git, especially now that autogen.sh is not included in the tarballs. -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: xf86-video-nv: 5 commits - compat/.gitignore configure.ac .gitignore Makefile.am man/.gitignore
On Thu, Nov 19, 2009 at 08:09:59PM -0500, Gaetan Nadon wrote: On Thu, 2009-11-19 at 16:34 -0800, Aaron Plattner wrote: Note that it's trying to copy from /no-such-directory/share/doc/util-macros/INSTALL even though util-macros was installed with --prefix=/usr. You're right, there was a hidden assumption that the prefix of util-macros was known. I don't think there is a reliable way of finding this information. This was an attempt to save from having to check-in 250 INSTALL file. A large number of modules did not have any. It looks like this is the only alternative now. How about making xorg-macros install a .pc file, then pkg-config --variable=prefix xorg-macros? Cheers, Daniel pgpsQivIl3ObV.pgp Description: PGP signature ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] util/modular/build.sh: remove xtrap extension protocol, library and app
On Thu, Nov 12, 2009 at 09:09:56PM -0500, Gaetan Nadon wrote:
From e7ff628d690955274fad3117fd3af567b96f9f1b Mon Sep 17 00:00:00 2001
From: Gaetan Nadon mems...@videotron.ca
Date: Thu, 12 Nov 2009 20:58:37 -0500
Subject: [PATCH] build.sh: remove xtrap extension protocol, library and app
This extension is considered obsolete and is no longer being
maintained, supported, or updated.
Equivalent functionality is provided in the XTest RECORD extensions,
as noted in:
http://lists.freedesktop.org/archives/xorg/2008-June/036131.html
---
build.sh |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/build.sh b/build.sh
index 15fdb23..ff0e77c 100755
--- a/build.sh
+++ b/build.sh
@@ -260,7 +260,6 @@ build_proto() {
build proto renderproto
build proto resourceproto
build proto scrnsaverproto
-build proto trapproto
build proto videoproto
build proto x11proto
build proto xcmiscproto
@@ -350,7 +349,6 @@ build_lib() {
build lib libXrandr
build lib libXRes
build lib libXScrnSaver
-build lib libXTrap
build lib libXtst
build lib libXv
build lib libXvMC
@@ -450,7 +448,6 @@ build_app() {
build app xsetroot
build app xsm
build app xstdcmap
-build app xtrap
build app xvidtune
build app xvinfo
build app xwd
--
1.6.0.4
Acked-by: Peter Hutterer peter.hutte...@who-t.net
Cheers,
Peter
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xfree86: Edid quirk for Philips LCD LP154W01
On Wed, 2009-11-18 at 18:04 +0800, Zhao, Yakui wrote:
From: Zhao Yakui yakui.z...@intel.com
Move the EDID quirk for Philips LCD LP154W01 as the panel reports the vertical
size in cm.
Hi, Keith/Ajax
How about this patch?
The incorrect quirk is applied to Philips LCD(154W01), which causes
that the incorrect DPI is obtained. In such case the user will get the
incorrect display.
thanks.
Yakui
https://bugs.freedesktop.org/show_bug.cgi?id=24482
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
hw/xfree86/modes/xf86EdidModes.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/hw/xfree86/modes/xf86EdidModes.c
b/hw/xfree86/modes/xf86EdidModes.c
index 449078e..356e51e 100644
--- a/hw/xfree86/modes/xf86EdidModes.c
+++ b/hw/xfree86/modes/xf86EdidModes.c
@@ -131,8 +131,11 @@ static Bool quirk_detailed_v_in_cm (int scrnIndex,
xf86MonPtr DDC)
return TRUE;
/* Bug #21000: LGPhilipsLCD LP154W01-TLAJ */
+/* Bug #10304: LGPhilipsLCD LP154W01-A5 */
if (memcmp (DDC-vendor.name, LPL, 4) == 0
- DDC-vendor.prod_id == 47360)
+ (DDC-vendor.prod_id == 47360 ||
+ DDC-vendor.prod_id == 0 ||
+ DDC-vendor.prod_id == 0x2a00))
return TRUE;
/* Bug #21750: Samsung Syncmaster 2333HD */
@@ -145,11 +148,6 @@ static Bool quirk_detailed_v_in_cm (int scrnIndex,
xf86MonPtr DDC)
static Bool quirk_detailed_use_maximum_size (int scrnIndex, xf86MonPtr DDC)
{
-/* Bug #10304: LGPhilipsLCD LP154W01-A5 */
-if (memcmp (DDC-vendor.name, LPL, 4) == 0
- (DDC-vendor.prod_id == 0 || DDC-vendor.prod_id == 0x2a00))
- return TRUE;
-
/* Bug #21324: Iiyama Vision Master 450 */
if (memcmp (DDC-vendor.name, IVM, 4) == 0
DDC-vendor.prod_id == 6400)
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
