bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#460: marked as done (23.0.60; x-display-color-cells returns 20 on w


From: Emacs bug Tracking System
Subject: bug#460: marked as done (23.0.60; x-display-color-cells returns 20 on w32 remote desktop)
Date: Thu, 19 Feb 2009 13:30:03 +0000

Your message dated Thu, 19 Feb 2009 21:23:21 +0800
with message-id <address@hidden>
and subject line 23.0.60; x-display-color-cells returns 20 on w32 remote desktop
has caused the Emacs bug report #460,
regarding 23.0.60; x-display-color-cells returns 20 on w32 remote desktop
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact address@hidden
immediately.)


-- 
460: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=460
Emacs Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 23.0.60; x-display-color-cells returns 20 on w32 remote desktop Date: Sat, 21 Jun 2008 22:27:50 +0100
When I run Emacs on my Windows machine and look at it with Remote
Desktop Connection on my Mac the modeline faces are black and white.
This is because the `mode-line' face is defined as inverse-video for
displays with less than 88 colors, and `x-display-color-cells' returns
20 when using RDC.

Here's a hacky patch that I installed locally.  It probably needs more
work before it's suitable for inclusion.  I first tried just checking
whether `cap' was less than 21 rather than checking for a negative
value, but then the function would return the wrong number of colors.
I had to use GetDeviceCaps to work out the color depth.


*** w32fns.c.~1.331.~ Wed Jun 18 2008 07:05:15 PM
--- w32fns.c Tue Jun 17 2008 05:59:23 PM
***************
*** 6711,6719 ****
  
    /* We force 24+ bit depths to 24-bit, both to prevent an overflow
       and because probably is more meaningful on Windows anyway */
!   if (cap < 0)
!     cap = 1 << min (dpyinfo->n_planes * dpyinfo->n_cbits, 24);
! 
--- 6710,6721 ----
      cap = GetDeviceCaps (hdc, NUMCOLORS);
  
    /* We force 24+ bit depths to 24-bit, both to prevent an overflow
       and because probably is more meaningful on Windows anyway */
!   /* Remote Desktop often returns 20 for NUMCOLORS device capability
!      when it can display more */
!   if (cap < 21)
!     cap = 1 << min (GetDeviceCaps (hdc, BITSPIXEL)
!                   * GetDeviceCaps (hdc, PLANES), 24);
    ReleaseDC (dpyinfo->root_window, hdc);
  
    return make_number (cap);


In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-06-21 on GOLDEN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENG
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Text

Minor modes in effect:
  delete-selection-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
[elided]

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
65536 [2 times]
Quit
Mark set



--- End Message ---
--- Begin Message --- Subject: 23.0.60; x-display-color-cells returns 20 on w32 remote desktop Date: Thu, 19 Feb 2009 21:23:21 +0800 User-agent: Thunderbird 2.0.0.19 (Windows/20081209) Looking into the code surrounding this, I found that we were getting the depth and other display properties explicitly from the desktop window. The docs suggest using NULL for the window handle when you don't have a window to explicitly use, so I've changed the code to do that, which might fix the bug if the cause is that the desktop window is set deliberately to use a 20 color palette even though the rest of the remote session supports more colors.

It is possible though that the remote desktop session is setting a low color palette to save bandwidth, but letting non-palette-aware applications draw in full color, since once the full color data has been transferred it makes no sense to artificially reduce it. If this is the case, then Emacs is doing the right thing by honoring the request to use a palette.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]