Updated Packages:
bridge-utils-1.1-1 ------------------ * Wed Jun 07 2006 David Woodhouse dwmw2@redhat.com 1.1-1 - Update to 1.1 - BR libsysfs-devel instead of sysfsutils-devel
hwdata-0.181-1 -------------- * Sat Jul 08 2006 Adam Jackson ajackson@redhat.com - 0.181-1 - Updated videodrivers to mention i945 - New monitors: Sony CPD-G420 (#145902), Compaq P1110 (#155120).
* Thu Jun 22 2006 Adam Jackson ajackson@redhat.com - 0.180-2 - Bump.
kbd-1.12-16 ----------- * Sun Jul 09 2006 Miloslav Trmac mitr@redhat.com - 1.12-16 - Don't include <asm/kbdio.h> on SPARC (#198040, patch by Dennis Gilmore dennis@ausil.us)
libpfm-3.2-0.060621.8 --------------------- * Sat Jul 08 2006 Will Cohen wcohen@redhat.com - Avoid pulling in the example ELF executable into /usr/share. (#198001) - Mark man pages as documentation.
ncurses-5.5-21 -------------- * Sat Jul 08 2006 Miroslav Lichvar mlichvar@redhat.com 5.5-21 - fix crash in tgetent (#198032)
xorg-x11-server-1.1.0-27.fc6 ---------------------------- * Sat Jul 08 2006 Kristian Høgsberg krh@redhat.com - 1.1.0-27.fc6 - Enable TLS for GLX to match the mesa build config.
* Fri Jul 07 2006 Kristian Høgsberg krh@redhat.com - 1.1.0-26 - Add xorg-x11-server-1.1.0-mesa-copy-sub-buffer.patch to hook up the GLX_MESA_copy_sub_buffer extension.
* Fri Jun 30 2006 Mike A. Harris mharris@redhat.com 1.1.0-25.fc5 - Start using the new %{dist} tag http://fedoraproject.org/wiki/DistTag experimentally in the package Release field to help prevent problems like (#197266) from occuring in the future.
Broken deps for i386 ---------------------------------------------------------- cpufreq-utils - 1:002-1.1.37.i386 requires libsysfs.so.1 device-mapper-multipath - 0.4.7-2.0.i386 requires libsysfs.so.1 lm_sensors - 2.10.0-2.i386 requires libsysfs.so.1 openhpi - 2.4.1-4.i386 requires libsysfs.so.1 samba - 3.0.23-0.RC3.i386 requires perl(Unicode::MapUTF8)
Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 bsf - 2.3.0-6jpp_4fc.noarch requires servletapi5 bsf - 2.3.0-6jpp_4fc.noarch requires tomcat5-jsp-2.0-api cpufreq-utils - 1:002-1.1.37.ppc64 requires libsysfs.so.1()(64bit) device-mapper-multipath - 0.4.7-2.0.ppc64 requires libsysfs.so.1()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 gnuplot-emacs - 4.0.0-11.ppc64 requires emacs iprutils - 2.1.4-1.ppc64 requires libsysfs.so.1()(64bit) jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 openhpi - 2.4.1-4.ppc64 requires libsysfs.so.1()(64bit) samba - 3.0.23-0.RC3.ppc64 requires perl(Unicode::MapUTF8) struts - 1.2.8-2jpp_12fc.ppc64 requires tomcat5-jsp-2.0-api struts - 1.2.8-2jpp_12fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_12fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5
Broken deps for ia64 ---------------------------------------------------------- device-mapper-multipath - 0.4.7-2.0.ia64 requires libsysfs.so.1()(64bit) rgmanager - 2.0.0-0.fc6.5.ia64 requires libcman.so.2()(64bit) rgmanager - 2.0.0-0.fc6.5.ia64 requires cman samba - 3.0.23-0.RC3.ia64 requires perl(Unicode::MapUTF8)
Broken deps for x86_64 ---------------------------------------------------------- cpufreq-utils - 1:002-1.1.37.x86_64 requires libsysfs.so.1()(64bit) device-mapper-multipath - 0.4.7-2.0.x86_64 requires libsysfs.so.1()(64bit) lm_sensors - 2.10.0-2.i386 requires libsysfs.so.1 lm_sensors - 2.10.0-2.x86_64 requires libsysfs.so.1()(64bit) openhpi - 2.4.1-4.x86_64 requires libsysfs.so.1()(64bit) openhpi - 2.4.1-4.i386 requires libsysfs.so.1 samba - 3.0.23-0.RC3.x86_64 requires perl(Unicode::MapUTF8)
Broken deps for ppc ---------------------------------------------------------- cpufreq-utils - 1:002-1.1.37.ppc requires libsysfs.so.1 device-mapper-multipath - 0.4.7-2.0.ppc requires libsysfs.so.1 iprutils - 2.1.4-1.ppc requires libsysfs.so.1 openhpi - 2.4.1-4.ppc requires libsysfs.so.1 samba - 3.0.23-0.RC3.ppc requires perl(Unicode::MapUTF8)
Broken deps for s390x ---------------------------------------------------------- device-mapper-multipath - 0.4.7-2.0.s390x requires libsysfs.so.1()(64bit) openCryptoki - 2.2.4-1.s390x requires PKCS11_ICA.so openCryptoki - 2.2.4-1.s390x requires PKCS11_API.so openCryptoki - 2.2.4-1.s390x requires libica.so()(64bit) openhpi - 2.4.1-4.s390 requires libsysfs.so.1 openhpi - 2.4.1-4.s390x requires libsysfs.so.1()(64bit) rgmanager - 2.0.0-0.fc6.5.s390x requires libcman.so.2()(64bit) rgmanager - 2.0.0-0.fc6.5.s390x requires cman samba - 3.0.23-0.RC3.s390x requires perl(Unicode::MapUTF8) yelp - 2.15.2-1.s390x requires libbeagle.so.0()(64bit)
Broken deps for s390 ---------------------------------------------------------- device-mapper-multipath - 0.4.7-2.0.s390 requires libsysfs.so.1 openCryptoki - 2.2.4-1.s390 requires libica.so openhpi - 2.4.1-4.s390 requires libsysfs.so.1 rgmanager - 2.0.0-0.fc6.5.s390 requires cman rgmanager - 2.0.0-0.fc6.5.s390 requires libcman.so.2 samba - 3.0.23-0.RC3.s390 requires perl(Unicode::MapUTF8) tomboy - 0.3.5-5.s390 requires mono(System.Xml) = 0:1.0.5000.0 tomboy - 0.3.5-5.s390 requires mono(dbus-sharp) = 0:0.60.0.0 tomboy - 0.3.5-5.s390 requires mono(mscorlib) = 0:1.0.5000.0 tomboy - 0.3.5-5.s390 requires mono(Mono.Posix) = 0:1.0.5000.0 tomboy - 0.3.5-5.s390 requires mono(gnome-sharp) = 0:1.0.0.0 tomboy - 0.3.5-5.s390 requires mono(glib-sharp) = 0:1.0.0.0 tomboy - 0.3.5-5.s390 requires mono(gmime-sharp) = 0:2.2.0.0 tomboy - 0.3.5-5.s390 requires mono(glib-sharp) = 0:2.8.0.0 tomboy - 0.3.5-5.s390 requires mono(gtk-sharp) = 0:1.0.0.0 tomboy - 0.3.5-5.s390 requires mono(gconf-sharp-peditors) = 0:1.0.0.0 tomboy - 0.3.5-5.s390 requires mono(System) = 0:1.0.5000.0 tomboy - 0.3.5-5.s390 requires mono(gdk-sharp) = 0:1.0.0.0 tomboy - 0.3.5-5.s390 requires mono(gconf-sharp) = 0:1.0.0.0 tomboy - 0.3.5-5.s390 requires mono(pango-sharp) = 0:1.0.0.0 tomcat5-webapps - 5.5.17-3jpp_1fc.s390 requires jakarta-taglibs-standard >= 0:1.1.0 yelp - 2.15.2-1.s390 requires libbeagle.so.0
buildsys@redhat.com wrote :
hwdata-0.181-1
- Sat Jul 08 2006 Adam Jackson ajackson@redhat.com - 0.181-1
- Updated videodrivers to mention i945
- New monitors: Sony CPD-G420 (#145902), Compaq P1110 (#155120).
There are also a bunch of Dell monitors that should be added : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196734
Matthias
Le dimanche 09 juillet 2006 à 13:23 +0200, Matthias Saou a écrit :
buildsys@redhat.com wrote :
hwdata-0.181-1
- Sat Jul 08 2006 Adam Jackson ajackson@redhat.com - 0.181-1
- Updated videodrivers to mention i945
- New monitors: Sony CPD-G420 (#145902), Compaq P1110 (#155120).
There are also a bunch of Dell monitors that should be added : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196734
BTW the full Belinea monitor range frequencies can be found there ftp://ftp.maxdata.com/10_Belinea_Monitors/40_Driver/Inf_files/Belinea_353.inf
if anyone is motivated to extract the info in hwdata format
Regards,
On Sun, Jul 09, 2006 at 02:11:28PM +0200, Nicolas Mailhot wrote:
Le dimanche 09 juillet 2006 ?? 13:23 +0200, Matthias Saou a ??crit :
buildsys@redhat.com wrote :
hwdata-0.181-1
- Sat Jul 08 2006 Adam Jackson ajackson@redhat.com - 0.181-1
- Updated videodrivers to mention i945
- New monitors: Sony CPD-G420 (#145902), Compaq P1110 (#155120).
There are also a bunch of Dell monitors that should be added : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196734
BTW the full Belinea monitor range frequencies can be found there ftp://ftp.maxdata.com/10_Belinea_Monitors/40_Driver/Inf_files/Belinea_353.inf
if anyone is motivated to extract the info in hwdata format
updated inf2mondb.py below. Go nuts. I use this to automatically extract monitor info from the Windows *.inf files our monitor teams post to support.dell.com. I find the --new option most useful.
Le dimanche 09 juillet 2006 à 08:50 -0500, Matt Domsch a écrit :
On Sun, Jul 09, 2006 at 02:11:28PM +0200, Nicolas Mailhot wrote:
Le dimanche 09 juillet 2006 ?? 13:23 +0200, Matthias Saou a ??crit :
buildsys@redhat.com wrote :
hwdata-0.181-1
- Sat Jul 08 2006 Adam Jackson ajackson@redhat.com - 0.181-1
- Updated videodrivers to mention i945
- New monitors: Sony CPD-G420 (#145902), Compaq P1110 (#155120).
There are also a bunch of Dell monitors that should be added : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196734
BTW the full Belinea monitor range frequencies can be found there ftp://ftp.maxdata.com/10_Belinea_Monitors/40_Driver/Inf_files/Belinea_353.inf
if anyone is motivated to extract the info in hwdata format
updated inf2mondb.py below. Go nuts. I use this to automatically extract monitor info from the Windows *.inf files our monitor teams post to support.dell.com. I find the --new option most useful.
Thanks a lot Matt! This file should IMHO end up in hwdata, at least in the doc section.
However it's not working on Belinea inf files - it can not find monitor names and generates this kind of list :
Belinea; ; MAX06CA; 30.0-83.0; 56.0-76.0 Belinea; ; MAX06B9; 30.0-97.0; 50.0-150.0 Belinea; ; MAX06D5; 30.0-83.0; 50.0-77.0 Belinea; ; MAX0BFE; 30.0-95.0; 50.0-160.0 Belinea; ; MAX0BE0; 30.0-86.0; 50.0-150.0 Belinea; ; MAX05EC; 31.0-62.0; 56.0-75.0
Can anyone help me on this ? i've not even reached the python-101 level yet :(
Le dimanche 09 juillet 2006 à 16:18 +0200, Nicolas Mailhot a écrit :
Le dimanche 09 juillet 2006 à 08:50 -0500, Matt Domsch a écrit :
On Sun, Jul 09, 2006 at 02:11:28PM +0200, Nicolas Mailhot wrote:
Le dimanche 09 juillet 2006 ?? 13:23 +0200, Matthias Saou a ??crit :
buildsys@redhat.com wrote :
hwdata-0.181-1
- Sat Jul 08 2006 Adam Jackson ajackson@redhat.com - 0.181-1
- Updated videodrivers to mention i945
- New monitors: Sony CPD-G420 (#145902), Compaq P1110 (#155120).
There are also a bunch of Dell monitors that should be added : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196734
BTW the full Belinea monitor range frequencies can be found there ftp://ftp.maxdata.com/10_Belinea_Monitors/40_Driver/Inf_files/Belinea_353.inf
if anyone is motivated to extract the info in hwdata format
updated inf2mondb.py below. Go nuts. I use this to automatically extract monitor info from the Windows *.inf files our monitor teams post to support.dell.com. I find the --new option most useful.
Thanks a lot Matt! This file should IMHO end up in hwdata, at least in the doc section.
However it's not working on Belinea inf files - it can not find monitor names and generates this kind of list :
Belinea; ; MAX06CA; 30.0-83.0; 56.0-76.0 Belinea; ; MAX06B9; 30.0-97.0; 50.0-150.0 Belinea; ; MAX06D5; 30.0-83.0; 50.0-77.0 Belinea; ; MAX0BFE; 30.0-95.0; 50.0-160.0 Belinea; ; MAX0BE0; 30.0-86.0; 50.0-150.0 Belinea; ; MAX05EC; 31.0-62.0; 56.0-75.0
Can anyone help me on this ? i've not even reached the python-101 level yet :(
I should add the Belinea inf files look like this : [Belinea] "Belinea 10 14 10" = 101410, Monitor\MAX0582 "Belinea 10 15 10" = 101510, Monitor\MAX05E6
...
[101410.AddReg] HKR,"MODES\1024,768",Mode1,,"30.0-61.0,50.0-77.0,+,+" HKR,,MaxResolution,,"1024,768" HKR,,DPMS,,1
[101510.AddReg] HKR,"MODES\1024,768",Mode1,,"30.0-61.0,50.0-77.0,+,+" HKR,,MaxResolution,,"1024,768" HKR,,DPMS,,1
Ok, with manual ugly tweaking (I don't know python) I generated the list I think the python script was confused by the " " in the monitor names
Full list attached at https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=132133
(bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198087)
It has 105 entries!!! The current hwdata only knows 4 Belinea screens
On Sun, Jul 09, 2006 at 05:43:11PM +0200, Nicolas Mailhot wrote:
Ok, with manual ugly tweaking (I don't know python) I generated the list I think the python script was confused by the " " in the monitor names
Did you actually change the python app? If so, please send me the patch you used. I'll look into quote escapes too.
Thanks, Matt
Le Lun 10 juillet 2006 14:55, Matt Domsch a écrit :
On Sun, Jul 09, 2006 at 05:43:11PM +0200, Nicolas Mailhot wrote:
Ok, with manual ugly tweaking (I don't know python) I generated the list I think the python script was confused by the " " in the monitor names
Did you actually change the python app? If so, please send me the patch you used. I'll look into quote escapes too.
Hi Matt
My "changes" where to create a custom Vendor for Belinea like you did for Dell, remove the python function around the monitor name printout (was nulling monitor names), and forcing "; 1" since as I read the inf file all Belinea monitors do DPMS but the app was not finding it.
Appart from the custom Belinea vendor, everything else are ugly brutal hacks you don't want in the app (like I said I don't know python at all;) )
I filtered the result in sed to remove quotes around monitor names, and sorted by monitor name.
And I filtered manually the output to simplify monitor names. Belinea often uses :
Belinea foo / Art. # bar as monitor name
which is ok when you have several foo variants with different bar numbers but heavy on the user when there is only one Belinea foo in existence.
The result is attached there: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198087
If you or someone else with more python foo than me can update the app to generate this list it will certainly be easier to maintain in the future. Belinea has release an awful lot of monitor variants - don't think it will be possible to track the list by hand.
Regards,
On Mon, 2006-07-10 at 07:55 -0500, Matt Domsch wrote:
On Sun, Jul 09, 2006 at 05:43:11PM +0200, Nicolas Mailhot wrote:
Ok, with manual ugly tweaking (I don't know python) I generated the list I think the python script was confused by the " " in the monitor names
Did you actually change the python app? If so, please send me the patch you used. I'll look into quote escapes too.
btw is someone looking at a "please insert the CD that came with your display" application that then mounts the CD, scans it for .inf files, imports those into the system and then unmounts the cd? (and maybe optionally sends the imported files to bugzilla ??? ;-)
Would be nice for novice users to get their monitor to work by doing what they expect.. eg put in the cd that came with it.
Greetings, Arjan van de Ven
Hi.
On Mon, 10 Jul 2006 15:34:23 +0200, Arjan van de Ven wrote:
btw is someone looking at a "please insert the CD that came with your display" application that then mounts the CD, scans it for .inf files, imports those into the system and then unmounts the cd? (and maybe optionally sends the imported files to bugzilla ??? ;-)
This may be a dead stupid question, but what do we acutally need this for? Don't all monitors report their values via DDC these days?
Arjan van de Ven wrote:
On Mon, 2006-07-10 at 15:41 +0200, Ralf Ertzinger wrote:
This may be a dead stupid question, but what do we acutally need this for? Don't all monitors report their values via DDC these days?
LCD's tend to not do that, and KVMs and stuff like that b0rks DDC as well...
Actually LCDs are better than most CRTs, external ones anyway. Internal panels sometimes lack a DDC channel (I think some LVDS connectors don't have space for the I2C pins), but ACPI is, in principle, supposed to give you the EDID info in the DSDT in that case. We don't use that block yet, mostly because I don't yet know how to map from ACPI tree node to PCI slot or the reverse, but I'm working on it.
KVM's are a weird breed. I've seen some that will just drop the I2C pins, some that pass it through only for the active node, and at least one in the lab that will provide _fake_ EDID info for the non-active machines (which, helpfully, matches /KVM/). I suspect the answer here is to get the server to cache the EDID info on disk.
- ajax
On Mon, 2006-07-10 at 15:41 +0200, Ralf Ertzinger wrote:
This may be a dead stupid question, but what do we acutally need this for? Don't all monitors report their values via DDC these days?
I've been having an annoying problem with at least one of my monitors. If I start the machine with the monitor off, the monitor doesn't respond to DDC. Which means the X server reverts to something like 1138x640@60. Xorg's 16:9 handling could use some work...
Which more an argument for supporting dynamic rescanning of the DDC info.
Usually I just hardcode scanning rates and resolutions because of stuff like this. For all I know, all monitors are like this...
Callum Lerwick wrote:
On Mon, 2006-07-10 at 15:41 +0200, Ralf Ertzinger wrote:
This may be a dead stupid question, but what do we acutally need this for? Don't all monitors report their values via DDC these days?
I've been having an annoying problem with at least one of my monitors. If I start the machine with the monitor off, the monitor doesn't respond to DDC. Which means the X server reverts to something like 1138x640@60. Xorg's 16:9 handling could use some work...
Which more an argument for supporting dynamic rescanning of the DDC info.
I believe the i810 driver is getting some work done in this area. Really though this isn't Fedora specific in any way, but is rather an upstream X.Org future feature enhancement.
Usually I just hardcode scanning rates and resolutions because of stuff like this. For all I know, all monitors are like this...
It's a good idea to hit http://bugs.freedesktop.org with any problems you encounter, to ensure the driver maintainers are aware of any issues.
HTH
Arjan van de Ven wrote:
On Mon, 2006-07-10 at 07:55 -0500, Matt Domsch wrote:
On Sun, Jul 09, 2006 at 05:43:11PM +0200, Nicolas Mailhot wrote:
Ok, with manual ugly tweaking (I don't know python) I generated the list I think the python script was confused by the " " in the monitor names
Did you actually change the python app? If so, please send me the patch you used. I'll look into quote escapes too.
btw is someone looking at a "please insert the CD that came with your display" application that then mounts the CD, scans it for .inf files, imports those into the system and then unmounts the cd? (and maybe optionally sends the imported files to bugzilla ??? ;-)
Would be nice for novice users to get their monitor to work by doing what they expect.. eg put in the cd that came with it.
I'm working on making it unnecessary. Would be useful for people with broken hardware that can't DDC though.
At this point the only reason we should need the monitors database at all is for pretty names in s-c-d. We should be taking nearly full advantage of EDID info in the X server now. Right now it's mostly a matter of making s-c-d aware of this.
- ajax
On Mon, 2006-07-10 at 09:50 -0400, Adam Jackson wrote:
Arjan van de Ven wrote:
On Mon, 2006-07-10 at 07:55 -0500, Matt Domsch wrote:
On Sun, Jul 09, 2006 at 05:43:11PM +0200, Nicolas Mailhot wrote:
Ok, with manual ugly tweaking (I don't know python) I generated the list I think the python script was confused by the " " in the monitor names
Did you actually change the python app? If so, please send me the patch you used. I'll look into quote escapes too.
btw is someone looking at a "please insert the CD that came with your display" application that then mounts the CD, scans it for .inf files, imports those into the system and then unmounts the cd? (and maybe optionally sends the imported files to bugzilla ??? ;-)
Would be nice for novice users to get their monitor to work by doing what they expect.. eg put in the cd that came with it.
I'm working on making it unnecessary. Would be useful for people with broken hardware that can't DDC though.
At this point the only reason we should need the monitors database at all is for pretty names in s-c-d. We should be taking nearly full advantage of EDID info in the X server now. Right now it's mostly a matter of making s-c-d aware of this.
Not only broken hardware, I have 3 monitors connected through RGBhv coax instead of the regular 15-pin VGA connector (Due to image quality at a 15m cable run at 1920x1440). Logically this excludes all DDC communications.
-HK
Arjan van de Ven (arjan@fenrus.demon.nl) said:
On Mon, 2006-07-10 at 07:55 -0500, Matt Domsch wrote:
On Sun, Jul 09, 2006 at 05:43:11PM +0200, Nicolas Mailhot wrote:
Ok, with manual ugly tweaking (I don't know python) I generated the list I think the python script was confused by the " " in the monitor names
Did you actually change the python app? If so, please send me the patch you used. I'll look into quote escapes too.
btw is someone looking at a "please insert the CD that came with your display" application that then mounts the CD, scans it for .inf files, imports those into the system and then unmounts the cd? (and maybe optionally sends the imported files to bugzilla ??? ;-)
Would be nice for novice users to get their monitor to work by doing what they expect.. eg put in the cd that came with it.
Actually, we're looking at just having X determine what monitors are there automatically, and throwing out most of this data for sane, modern, displays. :)
Bill
On Mon, 2006-07-10 at 15:07 -0400, Bill Nottingham wrote:
Arjan van de Ven (arjan@fenrus.demon.nl) said:
On Mon, 2006-07-10 at 07:55 -0500, Matt Domsch wrote:
On Sun, Jul 09, 2006 at 05:43:11PM +0200, Nicolas Mailhot wrote:
Ok, with manual ugly tweaking (I don't know python) I generated the list I think the python script was confused by the " " in the monitor names
Did you actually change the python app? If so, please send me the patch you used. I'll look into quote escapes too.
btw is someone looking at a "please insert the CD that came with your display" application that then mounts the CD, scans it for .inf files, imports those into the system and then unmounts the cd? (and maybe optionally sends the imported files to bugzilla ??? ;-)
Would be nice for novice users to get their monitor to work by doing what they expect.. eg put in the cd that came with it.
Actually, we're looking at just having X determine what monitors are there automatically, and throwing out most of this data for sane, modern, displays. :)
that would obviously be highly preferable ;)