Re: [PATCH] xprop: Add colored icon support
On Thu, 12 Nov 2009, Andy Spencer wrote: * Supports both 16 and 265 color terminals * 8 color output supports ascii and utf8 brightness Signed-off-by: Andy Spencer andy753...@gmail.com --- I'm not sure how to test for 16 and 256 color so I left them set to 0. The proper way is to check the terminal database (using newterm to open it, for instance, and tigetnum(colors) to get the value). + /* TODO: test for color */ + if (0 || 0) + tail += sprintf (tail, \33[0m); } -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] xprop: Add colored icon support
* Supports both 16 and 265 color terminals
* 16 color output supports ascii and utf8 brightness
Signed-off-by: Andy Spencer andy753...@gmail.com
---
Here's an updated patch that uses setupterm and tigetnum, it also adds a
check for curses and term.h in configure.ac..
When I test it in xterm, it says it only supports 8 colors, even though
running colortest works correctly with all 256 colors so I'm not sure
what's going on there.
From what I can tell, there's a difference in the color tables for 8
color and 16 color terminals? Does anyone have any suggestions on how to
actually test these? (e.g. old terminals that only support 8/16 colors)
configure.ac |4 +-
xprop.c | 122 +++--
2 files changed, 78 insertions(+), 48 deletions(-)
diff --git a/configure.ac b/configure.ac
index 58b49ee..f2b6380 100644
--- a/configure.ac
+++ b/configure.ac
@@ -37,7 +37,9 @@ AC_PROG_INSTALL
XORG_DEFAULT_OPTIONS
-AC_CHECK_HEADERS([wchar.h wctype.h langinfo.h])
+AC_CHECK_HEADERS([wchar.h wctype.h langinfo.h term.h])
+AC_SEARCH_LIBS(setupterm, curses)
+AC_SEARCH_LIBS(tigetnum, curses)
# Checks for pkg-config packages
PKG_CHECK_MODULES(XPROP, x11)
diff --git a/xprop.c b/xprop.c
index ea65013..eebe947 100644
--- a/xprop.c
+++ b/xprop.c
@@ -49,6 +49,13 @@ from The Open Group.
#include langinfo.h
#endif
+#ifdef HAVE_TERM_H
+#include term.h
+#else
+#define setupterm(...)
+#define tigetnum(...) 0
+#endif
+
#ifndef HAVE_WCTYPE_H
#define iswprint(x) isprint(x)
#endif
@@ -770,20 +777,21 @@ Format_Icons (const unsigned long *icon, int len)
alloced = 0;
-while (icon end)
-{
+while (icon end) {
unsigned long width, height;
int w, h;
int offset;
-
+ int colors;
+
width = *icon++;
height = *icon++;
offset = (tail - result);
-
+
alloced += 80; /* For the header */
- alloced += (width*4 + 8) * height; /* For the rows (plus padding)
*/
-
+ alloced += (width*14 + 8) * height; /* For the rows (plus padding)
*/
+ alloced += 3; /* For the footer */
+
result = Realloc (result, alloced);
tail = result[offset];
@@ -792,58 +800,76 @@ Format_Icons (const unsigned long *icon, int len)
tail += sprintf (tail, \tIcon (%lu x %lu):\n, width, height);
- if (width 144 || height 144)
- {
+ if (width 144 || height 144) {
tail += sprintf (tail, \t(not shown));
icon += width * height;
continue;
}
-
- for (h = 0; h height; ++h)
- {
+
+ setupterm(NULL, 0, 0);
+ colors = tigetnum(colors);
+
+ for (h = 0; h height; ++h) {
tail += sprintf (tail, \t);
-
- for (w = 0; w width; ++w)
- {
+
+ for (w = 0; w width; ++w) {
unsigned char a, r, g, b;
unsigned long pixel = *icon++;
- unsigned long brightness;
-
+
a = (pixel 0xff00) 24;
r = (pixel 0x00ff) 16;
g = (pixel 0xff00) 8;
b = (pixel 0x00ff);
-
- brightness =
- (a / 255.0) * (1000 - ((299 * (r / 255.0)) +
- (587 * (g / 255.0)) +
- (114 * (b / 255.0;
-
- if (is_utf8_locale())
- {
- static const char palette[][4] =
- {
-,
- \342\226\221, /* 25% */
- \342\226\222, /* 50% */
- \342\226\223, /* 75% */
- \342\226\210, /* 100% */
- };
- int idx;
-
- idx = (brightness * ((sizeof (palette)/sizeof(palette[0]))
- 1)) / 1000;
-
- tail += sprintf (tail, %s, palette[idx]);
- }
- else
- {
- static const char palette[] =
-
.'`,^:\;~-_+i!lI?/\\|()1{}[]rcvunxzjftLCJUYXZO0Qoahkbdpqwm*WMB8%$#@;
- int idx;
-
- idx = (brightness * (sizeof(palette) - 2)) / 1000;
-
- *tail++ = palette[idx];
+
+ if (colors = 256) {
+ unsigned char color;
+
+ color = 16 +
+ ((r48?0 : r116?1 : (r-116)/40+2) * 36) +
+ ((g48?0 : g116?1 : (g-116)/40+2) * 6) +
+ ((b48?0 : b116?1 : (b-116)/40+2) * 1);
+ tail += sprintf (tail, \33[7;38;5;%dm, color);
+ tail += sprintf (tail, );
+ } else {
+ unsigned
Re: LibX11 and libXrender dependency loop?
On Wed, Nov 11, 2009 at 4:40 PM, Alan Coopersmith alan.coopersm...@sun.comwrote: Jon Grosshart wrote: Here is LibX11: make[1]: Entering directory `/tmp/Xorg7.5/source/lib/ libX11-1.3.2/specs' Making all in libX11 make[2]: Entering directory `/tmp/Xorg7.5/source/lib/libX11-1.3.2/specs/libX11' GENlibX11.txt GENlibX11.ps GENlibX11.html GENlibX11.pdf gs: error while loading shared libraries: libXrender.so.1: cannot open shared object file: No such file or directory Your problem is an incorrectly installed gs (presumably being called via ps2pdf) - you shouldn't have installed it without it's dependencies. If ps2pdf wasn't installed, the pdf build would be skipped. How is one supposed to go building the libs section of X11R7.5? I'm using all versions that can be found in the 7.5 release directory. This one has me kinda stumped. But you somehow installed a ps2pdf that depended on libXrender either without libXrender first or deleted libXrender afterwards. Don't do that. -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering Alan had the right of it and I came to the same conclusion last night while I was out. gs was obviously referring to ghostscript and it even had something about LibX11.pdf on the next line. I removed ghostscript and it installed fine. I should have checked configure for a --without-docs argument but just removed gs instead. I already had renderproto installed along with all the other proto packages. The protoheaders are the first thing to get installed for obvious reasons. It's just that for some reason, I like to remove all old(release 7.4) xorg related packages when I'm building a new release (I'll build on my VC's), therefore ps2pdf was found but broken. Thanks all. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] xprop: Add colored icon support
On Thu, 12 Nov 2009, Andy Spencer wrote: * Supports both 16 and 265 color terminals * 16 color output supports ascii and utf8 brightness Signed-off-by: Andy Spencer andy753...@gmail.com --- Here's an updated patch that uses setupterm and tigetnum, it also adds a check for curses and term.h in configure.ac.. When I test it in xterm, it says it only supports 8 colors, even though running colortest works correctly with all 256 colors so I'm not sure what's going on there. then your $TERM is set incorrectly - you didn't say which emulator you're using. For example, it might be xterm-256color, or gnome-256color (even on Solaris, you can install ncurses's terminfo database, thereby getting usable data ;-) From what I can tell, there's a difference in the color tables for 8 color and 16 color terminals? Does anyone have any suggestions on how to actually test these? (e.g. old terminals that only support 8/16 colors) There's no reliable way to _ask_ the terminfo what it supports. (xterm does provide escape sequences, but those are missing or dummy'd out in other terminal emulators). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: LibX11 and libXrender dependency loop?
Beso wrote: apart the ps2pdf issue, i think that installing renderproto should fix the libXrender installation. After the renderproto and libXrender are installed then libX11 should install too, according that ps2pdf is correctly installed too. libXrender depends on libX11, so you can't build it first (unless you already have a working X environment installed). -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: LibX11 and libXrender dependency loop?
On Thu, Nov 12, 2009 at 9:44 AM, Alan Coopersmith alan.coopersm...@sun.comwrote: Beso wrote: apart the ps2pdf issue, i think that installing renderproto should fix the libXrender installation. After the renderproto and libXrender are installed then libX11 should install too, according that ps2pdf is correctly installed too. libXrender depends on libX11, so you can't build it first (unless you already have a working X environment installed). Right you are. @ Beso: The gs thing didn't click with me at first so I decided to throw libxrender before libX11 just for the hell of it because it was complaining of the missing libxrender lib. It wasn't libX11 that was complaining about the missing lib but rather ghostscript when libX11 was trying to build a pdf file (btw, who wants bloated pdf's on their system anyway ;-) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: keyboard suddenly dead
I had the same problem, I suspect it's a KDE bug - my colleague suggested to switch krunner to task oriented interface and back to command oriented. It helped, keyboard was working again after this. I didn't ask him how he found this solution, but he reported it in KDE bugzilla. cheers, Adam On Wed, Nov 11, 2009 at 6:46 PM, Hanno Böck ha...@hboeck.de wrote: Hi, I had a quite strange problem, it's not reproducible, but it happened twice, so I thought I'll report it, no idea how to investigate it further. Just suddenly, my keyboard in X stopped working. I could continue using all applications with the mouse and everything seemed fine, just all my keyboard inputs were ignored. I could however use ctrl-alt-f1 to switch to the console and there everything was fine, switching back and keyboard was dead again. Restarting X helped. This is the log, but I think it says nothing interesting: http://files.hboeck.de/Xorg.0.log.keyboarddead I'm using ~amd64 packages of gentoo linux, so mainly latest releases (xorg- server-1.7.1, xf86-input-evdev-2.3.0, xf86-video-intel-2.9.1, xf86-input- synaptics-1.2.0), computer is a lenovo t61 laptop with intel gpu. -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail: ha...@hboeck.de http://schokokeks.org - professional webhosting ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: radeon: different colors on different heads?
On Wed, Nov 11, 2009 at 9:29 PM, Csillag Kristof csillag.kris...@united-consult.hu wrote: Alex Deucher wrote: Does adjusting the gamma on the problematic head help? If I understand your question correctly, you suggest that the gamma correction function might be off. I don't think this is the case, because on my monitor, the relation between (at least) the blue part of the pixel data and the actually displayed color seems to be a non-monotonic function. See the photo I made about the color selection dialog from GIMP. (Before taking the picture, I stretched it out horizontally for best visibility.) On proper head: http://picasaweb.google.com/lh/photo/OB7B3DgO3LKLmL4NUxx5Jw?authkey=Gv1sRgCM60oc7kuoW24gEfeat=directlink On bogus head: http://picasaweb.google.com/lh/photo/ZRIy7uJmmPmVWxEcSmVTKg?authkey=Gv1sRgCM60oc7kuoW24gEfeat=directlink The current setting is FF (RGB), and as you can see, the gradient from 00 to FF (the 6th line, besides letter B), and the one from FF to 00 (the 5th line, besides letter G) are messed up in creative ways. (They should be monotonic, but they are not.) As far as I can tell, wrong gamma does not do that; it does not introduce non-monotonic transformations. It looks almost as if some bits of the blue data were sometime lost in transition. (But where?) Is the problematic screen the one driven by DVO or internal tmds? Post your Xorg log and specify which output is the problematic one (DVI-0 or DVI-1). Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Howto get cursor image of pointer other than the VCP
Hi there, Is it (as of X.org 7.5) possible to get the cursor image of some other master pointer which is not the Virtual Core Pointer? I guess XFixesGetCursorImage() just returns that of the VCP... Cheers, Christian -- what is, is; what is not is possible. signature.asc Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: radeon: different colors on different heads?
2009/11/12 Csillag Kristof csillag.kris...@united-consult.hu: Alex Deucher wrote: Is the problematic screen the one driven by DVO or internal tmds? Post your Xorg log and specify which output is the problematic one (DVI-0 or DVI-1). I have attached the log. The problematic head is DVI-1, which is driven by DVO. * * * One naive question: the FireMV 2200 card in question has one DMS-59 slot, which is then divided to two DVI-U ports with a special Y cable. I have purchased this Y cable separately, from ebay. Could it be that the problem is with this Y card? Could definitely be a problem with the cable, or a problem with the external tmds transmitter setup. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] xfree86: Edid quirk for Philips LCD LP154W01
From: Zhao Yakui yakui.z...@intel.com
Move the EDID quirk for Philips LCD LP154W01 as the panel reports the vertical
size in cm.
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)
--
1.5.4.5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] xfree86: Edid quirk for Philips LCD LP154W01
On Fri, 2009-11-13 at 09:34 +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, Ajax
The EDID in several Philips LCD monitor reports the panel vertical
size in cm, which causes that the user gets the incorrect DPI. So we
should add the EDID quirk for such display monitors.
In fact we also have the edid quirk for these display monitors. But
it is put into the wrong place.
Do you have an opportunity to look at this patch?
Thanks.
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 mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
