Bug#53752: marked as done (xlibs: Vietnamese (vi_VN) localization)
Your message dated Sun, 19 Sep 2004 09:02:52 +0200 with message-id [EMAIL PROTECTED] and subject line Bug#53752: xlibs: Vietnamese (vi_VN) localization has caused the attached Bug report 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 I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 30 Dec 1999 22:27:53 + Received: (qmail 18815 invoked from network); 30 Dec 1999 22:27:51 - Received: from chupacabras.flash.net (209.30.2.16) by master.debian.org with SMTP; 30 Dec 1999 22:27:51 - Received: from ghoti.home (209-30-246-231.flash.net [209.30.246.231]) by chupacabras.flash.net (8.9.3/Pro-8.9.3) with ESMTP id QAA27448 for [EMAIL PROTECTED]; Thu, 30 Dec 1999 16:27:22 -0600 (CST) Received: from aclark by ghoti.home with local (Exim 3.11 #1 (Debian)) id 123o2T-0007FX-00; Thu, 30 Dec 1999 16:27:21 -0600 From: Ashley Clark [EMAIL PROTECTED] Subject: xlib6g: Vietnamese (vi_VN) localization patch To: [EMAIL PROTECTED] X-Mailer: bug 3.2.7 Message-Id: [EMAIL PROTECTED] Date: Thu, 30 Dec 1999 16:27:21 -0600 Package: xlib6g Version: 3.3.5-2 Severity: wishlist Included is a patch enabling the vi_VN.TCVN and vi_VN.VISCII locales in Xlib. It was obtained from Pablo Saratxaga [EMAIL PROTECTED] who may or may not have submitted it upstream, if not it should be probably be forwarded upstream. Pablo's original patch also included changes for Georgian, Russian (KOI8-R, KOI8-U and Microsoft CP1251) but I have no way of testing them and so am only submitting the portions that deal with Vietnamese. I've tested this on my system and with the proper font encodings everything seems to work. -- System Information Debian Release: potato Kernel Version: Linux ghoti 2.2.13 #1 Wed Oct 20 08:50:54 CDT 1999 i586 unknown Versions of the packages xlib6g depends on: ii libc6 2.1.2-11 GNU C Library: Shared libraries and Timezone ii xfree86-common 3.3.5-3X Window System (XFree86) infrastructure - patch follows - --- xc/include/keysymdef.h.aclark Thu Dec 23 20:48:44 1999 +++ xc/include/keysymdef.h Thu Dec 23 20:54:44 1999 @@ -323,6 +323,22 @@ #defineXK_dead_voiced_sound0xFE5E #defineXK_dead_semivoiced_sound0xFE5F #defineXK_dead_belowdot0xFE60 +#define XK_dead_hook 0xFE61 +#define XK_dead_horn 0xFE62 +#define XK_dead_A 0xFE63 +#define XK_dead_a 0xFE64 +#define XK_dead_d 0xFE65 +#define XK_dead_D 0xFE66 +#define XK_dead_e 0xFE67 +#define XK_dead_E 0xFE68 +#define XK_dead_i 0xFE69 +#define XK_dead_I 0xFE6A +#define XK_dead_o 0xFE6B +#define XK_dead_O 0xFE6C +#define XK_dead_u 0xFE6D +#define XK_dead_U 0xFE6E +#define XK_dead_y 0xFE6F +#define XK_dead_Y 0xFE70 #defineXK_First_Virtual_Screen 0xFED0 #defineXK_Prev_Virtual_Screen 0xFED1 @@ -575,6 +591,7 @@ #define XK_Odiaeresis 0x0d6 #define XK_multiply0x0d7 #define XK_Ooblique0x0d8 +#define XK_Oslash XK_Ooblique #define XK_Ugrave 0x0d9 #define XK_Uacute 0x0da #define XK_Ucircumflex 0x0db @@ -608,6 +625,7 @@ #define XK_odiaeresis 0x0f6 #define XK_division0x0f7 #define XK_oslash 0x0f8 +#define XK_ooblique XK_oslash #define XK_ugrave 0x0f9 #define XK_uacute 0x0fa #define XK_ucircumflex 0x0fb @@ -1577,6 +1595,118 @@ #define XK_Korean_Won 0xeff #endif /* XK_KOREAN */ + +/* + * Vietnamese + * Byte 3 = 0x1e + */ + +#ifdef XK_VIETNAMESE +/* these two are from Latin8 and should be moved when it is added */ +#define XK_Ygrave 0x12ac +#define XK_ygrave 0x12bc +/* --- */ +#define XK_Abelowdot 0x1ea0 +#define XK_abelowdot 0x1ea1 +#define XK_Ahook 0x1ea2 +#define XK_ahook 0x1ea3 +#define XK_Acircumflexacute0x1ea4 +#define XK_acircumflexacute0x1ea5 +#define XK_Acircumflexgrave0x1ea6 +#define XK_acircumflexgrave0x1ea7 +#define XK_Acircumflexhook 0x1ea8 +#define XK_acircumflexhook 0x1ea9 +#define XK_Acircumflextilde0x1eaa +#define XK_acircumflextilde0x1eab +#define XK_Acircumflexbelowdot 0x1eac +#define XK_acircumflexbelowdot 0x1ead +#define
Bug#272180: marked as done (xlibs: abnt2 brazilian keyboard map definition with xkb misses ']' key)
Your message dated Sun, 19 Sep 2004 09:19:08 +0200
with message-id [EMAIL PROTECTED]
and subject line Bug#272180: xlibs: abnt2 brazilian keyboard map definition
with xkb misses ']' key
has caused the attached Bug report 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 I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--
Received: (at submit) by bugs.debian.org; 18 Sep 2004 02:36:30 +
From [EMAIL PROTECTED] Fri Sep 17 19:36:30 2004
Return-path: [EMAIL PROTECTED]
Received: from 200-207-126-53.dsl.telesp.net.br (arquivo.interno.etica.net)
[200.207.126.53]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1C8V5Q-0006pA-00; Fri, 17 Sep 2004 19:36:29 -0700
Received: from calvin.interno.etica.net
([192.168.1.223] helo=calvin ident=mail)
by arquivo.interno.etica.net with esmtp (Exim 4.34)
id 1C8V4e-00047X-BC
for [EMAIL PROTECTED]; Fri, 17 Sep 2004 23:35:40 -0300
Received: from wcal by calvin with local (Exim 3.32 #1 (Debian))
id 15hvrQ-gD-00; Fri, 14 Sep 2001 13:30:36 -0300
From: [EMAIL PROTECTED]
Subject: xlibs: abnt2 brazilian keyboard map definition with xkb misses ']' key
To: [EMAIL PROTECTED]
X-Mailer: bug 3.3.10
Message-Id: [EMAIL PROTECTED]
Date: Fri, 14 Sep 2001 13:30:36 -0300
X-arquivo.etica.net-MailScanner: Found to be clean
X-arquivo.etica.net-MailScanner-SpamCheck: não spam,
SpamAssassin (escore=1.693, requerido 5, BAYES_40 -0.00,
DATE_IN_PAST_96_XX 1.53, NO_REAL_NAME 0.16)
X-arquivo.etica.net-MailScanner-SpamScore: 1
X-MailScanner-From: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=0.8 required=4.0 tests=DATE_IN_PAST_96_XX,HAS_PACKAGE,
NO_REAL_NAME,ROUND_THE_WORLD_LOCAL autolearn=no
version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level:
Package: xlibs
Version: 4.1.0-5
Severity: normal
changing row 159 of /etc/X11/xkb/keycodes/xfree86 to
// alias AC12 = BKSL;
AC12 = 51;
instead of
alias AC12 = BKSL;
solved the problem.
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux calvin 2.4.9 #2 Qui Ago 30 15:48:59 BRT 2001 i686 unknown
Versions of the packages xlibs depends on:
ii libc6 2.2.4-1GNU C Library: Shared libraries and Timezone
ii libfreetype6 2.0.2.20010514 FreeType 2 font engine, shared library files
ii xfree86-common 4.1.0-5X Window System (XFree86) infrastructure
ii xlibs 4.1.0-5X Window System client libraries
--- Begin /etc/X11/xkb/keycodes/xfree86 (modified conffile)
// $Xorg: xfree86,v 1.3 2000/08/17 19:54:37 cpqbld Exp $
// $XFree86: xc/programs/xkbcomp/keycodes/xfree86,v 3.15 2001/01/17 23:45:51
dawes Exp $
// standard XFree86 codes
// It seems that the default must be the first entry in the file.
default xkb_keycodes xfree86 {
include xfree86(basic)
BKSL = 51;
LSGT = 94;
};
xkb_keycodes basic {
minimum= 8;
maximum= 255;
TLDE = 49;
AE01 = 10;
AE02 = 11;
AE03 = 12;
AE04 = 13;
AE05 = 14;
AE06 = 15;
AE07 = 16;
AE08 = 17;
AE09 = 18;
AE10 = 19;
AE11 = 20;
AE12 = 21;
BKSP = 22;
TAB = 23;
AD01 = 24;
AD02 = 25;
AD03 = 26;
AD04 = 27;
AD05 = 28;
AD06 = 29;
AD07 = 30;
AD08 = 31;
AD09 = 32;
AD10 = 33;
AD11 = 34;
AD12 = 35;
RTRN = 36;
CAPS = 66;
AC01 = 38;
AC02 = 39;
AC03 = 40;
AC04 = 41;
AC05 = 42;
AC06 = 43;
AC07 = 44;
AC08 = 45;
AC09 = 46;
AC10 = 47;
AC11 = 48;
LFSH = 50;
AB01 = 52;
AB02 = 53;
AB03 = 54;
AB04 = 55;
AB05 = 56;
AB06 = 57;
AB07 = 58;
AB08 = 59;
AB09 = 60;
AB10 = 61;
RTSH = 62;
LALT = 64;
LCTL = 37;
SPCE = 65;
RCTL = 109;
RALT = 113;
// Microsoft keyboard extra keys
LWIN = 115;
RWIN = 116;
MENU = 117;
ESC = 9;
FK01 = 67;
FK02 = 68;
FK03 = 69;
FK04 = 70;
FK05 = 71;
FK06 = 72;
FK07 = 73;
FK08 = 74;
FK09 = 75;
FK10 = 76;
FK11 = 95;
FK12 = 96;
PRSC = 111;
SYRQ = 92;
SCLK = 78;
PAUS = 110;
BRK = 114;
INS = 106;
HOME = 97;
PGUP = 99;
DELE = 107;
END = 103;
PGDN = 105;
UP = 98;
LEFT = 100;
DOWN = 104;
RGHT = 102;
NMLK = 77;
KPDV = 112;
KPMU = 63;
KPSU = 82;
KP7 = 79;
KP8
Bug#271235: (no subject)
I noticed another interesting thing when I do these steps: - I run xine and watch a movie for a few seconds, quit - I run tvtime - I observe the behavior I described (incorrect redrawing, only part of the image in fullscreen), quit - I run mplayer and watch a movie, quit - I run tvtime - no more incorrect behavior I'm encoutering this with dfsg.1-7 and nv_drv.o from 1-4 or NVIDIA driver 1.0.6111. Needless to say there was no such behavior before upgrading to 1-7. IMHO this shows that more things are broken in 1-7 than only the nv driver. Let me know if there's anything I can test. Andrei -- [EMAIL PROTECTED] # http://movzx.net # ICQ: 52641547
Bug#234057: marked as done (libxcursor1: cursor themes do not work on SPARC)
Your message dated Sun, 19 Sep 2004 14:32:31 + with message-id [EMAIL PROTECTED] and subject line fixed has caused the attached Bug report 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 I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 21 Feb 2004 16:10:17 + From [EMAIL PROTECTED] Sat Feb 21 08:10:17 2004 Return-path: [EMAIL PROTECTED] Received: from cd5112126.cable.wanadoo.nl (ultra) [213.17.33.38] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1AuZho-z4-00; Sat, 21 Feb 2004 08:10:17 -0800 Received: from compukid by ultra with local (Exim 3.36 #1 (Debian)) id 1AuZhn-XL-00; Sat, 21 Feb 2004 17:10:15 +0100 Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Daniel van Eeden [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Subject: xlibs-data: cursor themes don't work on sparc X-Mailer: reportbug 2.48 Date: Sat, 21 Feb 2004 17:10:14 +0100 Message-Id: [EMAIL PROTECTED] Sender: Daniel van Eeden [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_02_18 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-5.0 required=4.0 tests=HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2004_02_18 X-Spam-Level: Package: xlibs-data Version: 4.3.0-2 Severity: normal I've pointed /etc/alternatives/x-cursor-theme at /etc/X11/cursors/redglass.theme but my cursor stays black. I tried to s/core/redglass/ in /usr/X11R6/lib/X11/icons/default/index.theme but nothing changes. Daniel van Eeden [EMAIL PROTECTED] -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: sparc (sparc64) Kernel: Linux 2.4.21 Locale: LANG=C, LC_CTYPE=C -- no debconf information --- Received: (at 234057-close) by bugs.debian.org; 19 Sep 2004 14:32:33 + From [EMAIL PROTECTED] Sun Sep 19 07:32:33 2004 Return-path: [EMAIL PROTECTED] Received: from smtp05.wanadoo.nl [194.134.35.145] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1C92jx-0007jG-00; Sun, 19 Sep 2004 07:32:33 -0700 Received: from elite.driebergenweb.org (c53750c57.cable.wanadoo.nl [83.117.12.87]) by smtp5.wanadoo.nl (Postfix) with ESMTP id 840D6849C for [EMAIL PROTECTED]; Sun, 19 Sep 2004 16:32:31 +0200 (CEST) Subject: fixed From: Daniel van Eeden [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain Date: Sun, 19 Sep 2004 14:32:31 + Message-Id: [EMAIL PROTECTED] Mime-Version: 1.0 X-Mailer: Evolution 1.5.94 Content-Transfer-Encoding: 7bit Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-3.0 required=4.0 tests=BAYES_00 autolearn=no version=2.60-bugs.debian.org_2004_03_25 X-Spam-Level: It seems to be fixed. :)
Still having lots of trouble with Alt/Meta keys
I added some information to #259740, but I'm hopelessly confused as to what bug which bug report is describing; nothing discussed in that bug report has helped me so far. I'm trying to use altwin:meta_win. Trying very, very hard, in fact. Not in any complicated X applications; just in xterm. This is with the -7 packages installed. To take my window manager out of the picture, I started a clean X server running nothing except for a single xterm. The xterm is running zsh. At this point I have no options set (not even altwin:meta_win); generic pc104. This should be easy to reproduce. All I want is for my Windows keys to send Meta, and xterm to treat that like Escape. This requires XTerm*metaSendsEscape: true. [For some reason, I have to start an xterm, run xrdb in it, and start a new xterm for this to take effect. I can't run it from a VT with $DISPLAY set; it just switches to the X server instead of merging resources. Huh.] This all used to work after setxkbmap -option altwin:meta_win. Now I'm having trouble. Here's what xmodmap looks like when I start: shift Shift_L (0x32), Shift_R (0x3e) lockCaps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1Alt_L (0x40), Alt_L (0x7d), Meta_L (0x9c) mod2Num_Lock (0x4d) mod3 mod4Super_L (0x7f), Hyper_L (0x80) mod5Mode_switch (0x5d), ISO_Level3_Shift (0x7c) At this point alt-b generates backwards word and windows-b generates b. Without metaSendsEscape alt-b generates an accented a. I turn on altwin:meta_win: shift Shift_L (0x32), Shift_R (0x3e) lockCaps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1Alt_L (0x40), Alt_L (0x7d) mod2Num_Lock (0x4d) mod3 mod4Meta_L (0x73), Meta_R (0x74), Super_L (0x7f), Hyper_L (0x80), Meta_L (0x9c) mod5Mode_switch (0x5d), ISO_Level3_Shift (0x7c) Now neither alt-b nor windows-b produces any effect. If I use 'xmodmap -e clear mod1', then alt-b generates backspace-word and windows-b generates an accented a - this is what I wanted, and used to get, I think. If I do 'xmodmap -e add mod1 = Alt_L', then neither windows-b nor alt-b produces any effect again. If I do 'xmodmap -e add mod1 = Alt_R', so that both Alt_L and Alt_R are mapped to mod1, then Alt-b generates backwards word and Windows-b generates b. All of the above, mind you, is using the _left_ alt and windows keys. I haven't even tried the right ones, since I usually use the left when typing. So adding Alt_R to mod1 changes the behavior of both left keys... I can't reproduce all of these results in another server with GNOME and Metacity running - specifically, with mod1 cleared, Alt-b generates b instead of the accented a. I assume that's either GNOME or Metacity somehow eating the modifier. Right now I don't care. It's the keyboard cursor movement that I need. This is all terribly confusing, and it's a real shame that we're going to carry it into Sarge, IMO. But most of all I'd like advice on how to make the simple case of using altwin:meta_win work in xterm. All ideas appreciated. -- Daniel Jacobowitz
$B$$J$?$N%%$%G%#%!pJs$r$*Gd$j2$5$$!#(B
--- 突然、スパム的なメールをお送りしまして誠に申し訳ございません。 このメールは特定電子メールの送信の適正化等に関する法律に基 づく特定電子メールです。 http://www.soumu.go.jp/joho_tsusin/top/meiwaku.html 不要の方は即刻、削除して下さい。 --- この度は突然のメールをお送り致しまして本当に申し訳ありません。 決していかがわしい内容ではありませんのでご一読下さい。 不要であれば即刻削除してください。 あなた様のアイディアや情報を私どもワクワクネットクラブにお売りして 頂きたく、今回このようなメールをお送りさせて頂きました。 世の中、物はあふれ、需要が落ち込む中、新たな商材として「情報」が 売れています。 「何それ？情報が売れる」 ~~ と、思われるかもしれませんね。 それはどう言う事なのか簡単に説明させていただきます。 ●「おいしいパンを作れる小麦粉」は要らないけれど、 「おいしいパンの作り方」は知りたい。 ●「ディズニーランドの格安チケット」は、今は要らないけど 「チケットを格安で購入できる方法」は知りたい。 もっと簡単に例えると、 ●「道路地図」は要らないけど 「渋滞知らずの抜け道マップ」なら欲しい。買いたい。 という事なのです。 実際、あるアンケート結果では --- ■「インターネットの利用目的は？」の問いに対して、 1位・メール 2位 情報収集 3位ショッピング --- となっています。欲しい情報ならば「知りたい」だけでなく、 「お金を出してもいい！」とりわけ、インターネットを頻繁に使うユーザーに とって「情報は買うもの」と言う認識が一般的になってきたのです。 逆を言えばインターネットのマーケットでは、 「アイディアや情報は売れる！」と言う事なのです。 私どもワクワクネットクラブは、 これらの多くのアイディアや情報を集約し、知るだけでなく 「それらをどうビジネスに結びつけるか？」 を、会員の方に提案するサービスを提供しております。 ですから少しでも多くのアイディアや情報が欲しいのです。 ■あなたが知っているアイディアや情報を私どもにお売り下さい。 ■内容にもよりますが、5.000円〜100.000円で買い取らせて頂きます。 詳しくは、 http://www.0274.net/WAKUWAKU/ にアクセスして頂き、内容をご理解頂ければ幸いと存じます。 あなた様からのアイディア・情報の売り込みをお待ちしております。 何卒よろしくお願い申し上げます。 突然のメールでたいへん申し訳ありませんでした。 深く深くお詫び申し上げます。 -- ■特定電子メールの送信の適正化等に関する法律に基づく表記 送信者の氏名：白銀 アキラ [EMAIL PROTECTED] 受信拒否：下記をクリックして配信停止処理を行なって下さい。 --- 今後メールを希望されない方は以下のＵＲＬをクリックしてください。 http://ajk.dynsite.net/cgi-bin/CA/ml_act.cgi?mode=del[EMAIL PROTECTED]
Bug#271235: Bug#270228: Bug#269025: new nv driver. please test!
Fabio Massimo Di Nitto wrote: Ok thanks! Yes we are aware of the XV problem. Can you try to use xine and see if that works? We have a couple of reports where it is only mplayer having problems. Please also attach the output of xvinfo. It will help us isolating the problem that seems to be specific to a range of nvidia cards and not all of them. snip xine does work - I'm using -V xv to try and force it to use XVideo. It seems to be, and with --verbose=2 it has this as part of the output: video_out_xv: using Xv port 61 from adaptor NV Video Overlay for hardware colorspace conversion and scaling. video_out_xv: double buffering mode = 1 video_out_xv: port attribute XV_COLORKEY (6) value is 66046 video_out_xv: port attribute XV_AUTOPAINT_COLORKEY (7) value is 1 video_out_xv: port attribute XV_BRIGHTNESS (5) value is -32 video_out_xv: port attribute XV_CONTRAST (4) value is 4064 video_out_xv: port attribute XV_SATURATION (3) value is 4064 video_out_xv: ignoring broken XV_HUE settings on NVidia cardsvideo_out_xv: this adaptor supports the yuy2 format. video_out_xv: this adaptor supports the yv12 format. Thanks, Dave here is the output of xvinfo: X-Video Extension version 2.2 screen #0 Adaptor #0: NV Video Overlay number of ports: 1 port base: 61 operations supported: PutImage supported visuals: depth 24, visualID 0x23 depth 24, visualID 0x24 depth 24, visualID 0x25 depth 24, visualID 0x26 depth 24, visualID 0x27 depth 24, visualID 0x28 depth 24, visualID 0x29 depth 24, visualID 0x2a number of attributes: 9 XV_DOUBLE_BUFFER (range 0 to 1) client settable attribute client gettable attribute (current value is 1) XV_COLORKEY (range 0 to 16777215) client settable attribute client gettable attribute (current value is 66046) XV_AUTOPAINT_COLORKEY (range 0 to 1) client settable attribute client gettable attribute (current value is 1) XV_SET_DEFAULTS (range 0 to 0) client settable attribute XV_BRIGHTNESS (range -512 to 511) client settable attribute client gettable attribute (current value is -32) XV_CONTRAST (range 0 to 8191) client settable attribute client gettable attribute (current value is 4064) XV_SATURATION (range 0 to 8191) client settable attribute client gettable attribute (current value is 4064) XV_HUE (range 0 to 360) client settable attribute client gettable attribute (current value is 0) XV_ITURBT_709 (range 0 to 1) client settable attribute client gettable attribute (current value is 0) maximum XvImage size: 2046 x 2046 Number of image formats: 4 id: 0x32595559 (YUY2) guid: 59555932--0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132--0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x59565955 (UYVY) guid: 55595659--0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x30323449 (I420) guid: 49343230--0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) Adaptor #1: NV Video Blitter number of ports: 32 port base: 62 operations supported: PutImage supported visuals: depth 24, visualID 0x23 depth 24, visualID 0x24 depth 24, visualID 0x25 depth 24, visualID 0x26 depth 24, visualID 0x27 depth 24, visualID 0x28 depth 24, visualID 0x29 depth 24, visualID 0x2a no port attributes defined maximum XvImage size: 2046 x 2046 Number of image formats: 5 id: 0x32595559 (YUY2) guid: 59555932--0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132--0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x59565955 (UYVY) guid: 55595659--0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x30323449 (I420) guid: 49343230--0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x3 guid: 0300--0010-8000-00aa00389b71 bits per pixel: 32 number of planes: 1 type: RGB (packed) depth: 24 red, green, blue masks: 0xff, 0xff00, 0xff
Bug#173565: This is an alert from eSafe
*** eSafe detected hostile content in this email. *** Time: 19 Sep 2004 13:22:01 Scan result: Mail rejected Protocol: SMTP in File Name\Mail Subject: mail_1095772008: Mail Delivery (failure [EMAIL PROTECTED]) Source: [EMAIL PROTECTED] Destination: [EMAIL PROTECTED] Details: Mail infected with x-wav exploit \HTML Active Content: Found the following Html Tag Exploit: A^sHREF^s=cid^s:*
Bug#271542: xlibs: Can't get Meta and Alt to work correctly
On Mon, Sep 13, 2004 at 06:32:46PM +0200, Lionel Elie Mamane wrote: [...] When starting up X, the following behaviour happens: - Emacs does not recognise Meta as Meta, but recognises Alt as Meta, which it shouldn't. Note that if I remember well, Emacs automatically treats Alt as Meta if it thinks the current keymap does not have a Meta. This might be what is happening. See #255286. - TeXmacs recognises Alt as Alt, but not Meta. Quite hard to investigate until #255286 is fixed. - sawfish does not recognise Alt as Alt, but recognises Meta as Meta. See #263073. Which makes me very confused as to what could be wrong. The problem is that changes were made upstream in xlibs to improve support for multiple layouts. Some applications are confused and fail to handle the current keymaps. So there are 2 solutions: a. Fix xlibs. b. Fix those applications. (b) is most of the time trivial and safe (ie. a working configuration is not broken by applying this patch). OTOH changes in xlibs are very tricky and fragile, and AFAICT such changes have currently been performed neither by upstreams (XFree86 or Xorg) nor by other distributions, so I am afraid that Debian XFree86 maintainers are very reluctant to go for (a). Denis
Re: Still having lots of trouble with Alt/Meta keys
On Sun, Sep 19, 2004 at 03:00:27PM -0400, Daniel Jacobowitz wrote: [...] Without metaSendsEscape alt-b generates an accented a. I turn on altwin:meta_win: shift Shift_L (0x32), Shift_R (0x3e) lockCaps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1Alt_L (0x40), Alt_L (0x7d) mod2Num_Lock (0x4d) mod3 mod4Meta_L (0x73), Meta_R (0x74), Super_L (0x7f), Hyper_L (0x80), Meta_L (0x9c) mod5Mode_switch (0x5d), ISO_Level3_Shift (0x7c) Now neither alt-b nor windows-b produces any effect. This is already fixed in SVN. I sent a patch to upstream which has been accepted, but it has side effects and needs to be reverted. The bogus patch is http://bugzilla.xfree86.org/attachment.cgi?id=1197 and has to be (un)applied against /etc/X11/xkb/symbols/altwin. I can't reproduce all of these results in another server with GNOME and Metacity running - specifically, with mod1 cleared, Alt-b generates b instead of the accented a. I assume that's either GNOME or Metacity somehow eating the modifier. Right now I don't care. It's the keyboard cursor movement that I need. There are other issues with Metacity (#272208), see #271542 for some ideas on how to solve these bugs. Denis
Bug#271542: xlibs: Can't get Meta and Alt to work correctly
On Sun, Sep 19, 2004 at 10:35:08AM +0200, Denis Barbier wrote:
[...]
The problem is that changes were made upstream in xlibs to improve support
for multiple layouts. Some applications are confused and fail to handle
the current keymaps.
So there are 2 solutions:
a. Fix xlibs.
b. Fix those applications.
[...]
I should have mentioned that there is a 3rd way, which is to add an
option to disable fake keys. It will revert fixes applied against
pristine 4.3.0 and bugs will surface again when this option is
activated. I believe that this option should be added for sarge,
but users have to be warned that it is unuspported, ie. if this
option causes trouble to some users, their only choice is to
deactivate it.
It can be defined by:
partial function_keys
xkb_symbols no_fake_keys {
modifier_map none { META, SUPR, HYPR };
};
and rules/xfree.{lst,xml} must be updated too.
XSF guys, what do you think about it?
Denis
Re: Still having lots of trouble with Alt/Meta keys
On Sun, Sep 19, 2004 at 10:26:52PM +0200, Denis Barbier wrote: On Sun, Sep 19, 2004 at 03:00:27PM -0400, Daniel Jacobowitz wrote: [...] Without metaSendsEscape alt-b generates an accented a. I turn on altwin:meta_win: shift Shift_L (0x32), Shift_R (0x3e) lockCaps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1Alt_L (0x40), Alt_L (0x7d) mod2Num_Lock (0x4d) mod3 mod4Meta_L (0x73), Meta_R (0x74), Super_L (0x7f), Hyper_L (0x80), Meta_L (0x9c) mod5Mode_switch (0x5d), ISO_Level3_Shift (0x7c) Now neither alt-b nor windows-b produces any effect. This is already fixed in SVN. I sent a patch to upstream which has been accepted, but it has side effects and needs to be reverted. The bogus patch is http://bugzilla.xfree86.org/attachment.cgi?id=1197 and has to be (un)applied against /etc/X11/xkb/symbols/altwin. Thanks a lot! I saw this when I was going through the bug logs, but I thought it already had been. If I unapply that patch, Windows-b correctly produces escape-b in my xterm again. I can't reproduce all of these results in another server with GNOME and Metacity running - specifically, with mod1 cleared, Alt-b generates b instead of the accented a. I assume that's either GNOME or Metacity somehow eating the modifier. Right now I don't care. It's the keyboard cursor movement that I need. There are other issues with Metacity (#272208), see #271542 for some ideas on how to solve these bugs. Thanks. I'll leave that to someone else, since I mostly needed Meta. -- Daniel Jacobowitz
