Re: Dead keys not working.

[Ilya Anfimov]

On Thu, Aug 12, 2021 at 07:00:08PM +, Jose Otero wrote:
>Hi,
>I am unable to make dead keys work in my system, so maybe someone can
>point me to the right path.
>Sorry for throwing in FreeBSD specific terms in this firs paragraph, but
>just for context:
>I am using FreeBSD (13.0). First, I had installed the metaport (i.e.
>metapackage, the whole thing) for X.Org; and dead keys worked.
>A few weeks ago I had to reinstall all the ports (user programs),
>including X.Org. Going minimalistic I installed xorg-minimal,
>x11-drivers/xf86-input-keyboard, x11-drivers/xf86-input-mouse,
>x11/libXinerama, x11-fonts/libXft, x11/xorg-docs, and a couple of fonts
>(x11-fonts/xorg-fonts-truetype, x11-fonts/dejavu, x11-fonts/terminus-ttf).
>Dead keys do not work now, so I am likely missing some library.
>Just to complete the background, I am using suckless windon manager (dwm)
>and terminal (st). Just in case, dead keys don't work either in xterm, I
>already tried. Or other applications for that matter, e.g. qutebrowser.
>Now the details:
>If I try, for example, to write 'a' by typing ''' and then 'a'. It only
>writes 'a'. This is the info gather by xev for these events:
>https://pastebin.com/AEtVqNyT

 Well, I don't know exactly what is the path of X11 datafiles
on FreeBSD, it may be different than /usr/share/X11/

 However, considering that it is /usr/share/X11 -- you'll need the following
for deadkeys to work on C.UTF-8 locale:

File: /usr/share/X11/locale/locale.alias
Strings:

C.UTF-8 en_US.UTF-8
C.UTF-8:en_US.UTF-8


File: /usr/share/X11/locale/locale.dir
Strings:

en_US.UTF-8/XLC_LOCALE  en_US.UTF-8
en_US.UTF-8/XLC_LOCALE: en_US.UTF-8


File: /usr/share/X11/locale/en_US.UTF-8/Compose
Strings:
 : "ц║"   aacute # LATIN SMALL LETTER A 
WITH ACUTE

(Sorry about symbol in quotes, it should be utf-8 dead acute)


File: /usr/share/X11/locale/en_US.UTF-8/XI18N_OBJS
Strings:

XLC common/xlcUTF8Load  _XlcUtf8Loader  # XLC_open
XOM common/xomGeneric   _XomGenericOpenOM   # XOM_open
XIM common/ximcp_XimOpenIM _XimRegisterIMInstantiateCallback  
_XimUnRegisterIMInstantiateCallback # XIM_openXIM_register XIM_unregister

Most probably, you don't have the entire
/usr/share/X11/locale/en_US.UTF-8
directory, and it should be installed from some locale package.

Re: Stale image on X11 server after lost connection

[Ilya Anfimov]

On Thu, Apr 08, 2021 at 10:37:55AM +0200, Jos?? Tom??s Tocino Garc??a wrote:
>I'm afraid the machine with the X11 server has no mouse or keyboard
>attached to it, so I cannot "right click" it. It's something like a kiosk.

Anyway:  usually  the server is launched by some display manager,
or sometimes by the xinit command invocation from some script.

 In either case it launches something like Xsession  script  with
clients  run  from it, and waits until that script finishes, then
stops or restarts the server.

 Probably, there are mwm window manager invocation  as  the  last
command  of  that Xsession script, that runs mwm and the mwm runs
forever.
 You can change it to run mwm in background, and  make  the  last
command  some kind of a watchdog, that checks the server for your
application and exits when cannot find it -- making  the  server  
to  exit when your app exits.

 In any case, extensive scripting could solve many problems.

>El jue, 8 abr 2021 a las 9:57, Chris Sorenson ()
>escribio:
> 
>  >
>  > Re: Stale image on X11 server after lost connection
> 
>  >
>  > Message: 1
>  >Date: Tue, 6 Apr 2021 14:05:26 +0200
>  > From: Jos? Tom?s Tocino Garc?a
>  > To: Ilya Anfimov , xorg@lists.x.org
>  > Subject: Re: Stale image on X11 server after lost connection
>  > Message-ID:
>  >
>  > I'm sorry for the late reply. I've realized I made a mistake in the
>  initial
>  > post, the server is actually running motif windows manager.
>  >
>  > The output of xlsclients is:
>  >
>  > # xlsclients -al
>  > Window 0x60005b:
>  > Machine: localhost.localdomain
>  > Name: mwm
>  > Icon Name: mwm
>  > Command: /usr/bin/mwm
>  > Instance/Class: mwm/Mwm
>  >
> 
>  Give this a try: Right click the desktop, the root menu should popup,
>  select "Restart..."
> 
>  ___
>  xorg@lists.x.org: X.Org support
>  Archives: http://lists.freedesktop.org/archives/xorg
>  Info: https://lists.x.org/mailman/listinfo/xorg
>  Your subscription address: %(user_address)s
> 
>--
>Jose Tomas Tocino
>http://josetomastocino.com
>http://cadizenmoto.com

> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Stale image on X11 server after lost connection

[Ilya Anfimov]

On Wed, Feb 17, 2021 at 05:13:45PM +0100, Jos?? Tom??s Tocino Garc??a wrote:
>Hello.
>I have an xorg server running in a Linux box with no wm, and a separate
>machine running an application exporting to the X server in the first
>machine.
> 
>The problem arises when the connection is lost between the two machines or
>the application exporting the display fails. The X111 server keeps a stale
>image on screen that is obviously unresponsive. I'd rather it turn black
>the moment the connection is lost.
> 
>Is there a way of forcing the X server to stop showing that stale image
>when the connection is lost? Not sure if it has something to do with it
>not having a wm.
>Thanks!
>Regards.

 This looks rather strange. Usually connection failures
closes tcp socket, then windows, created by the
app should be destroyed be the server.
 What does xlsclients -al and xwininfo -root -tree show
before and after failure?
 Does the client still connected? Does it's window(s) still exists?

>--
>Jose Tomas Tocino
>http://josetomastocino.com
>http://cadizenmoto.com

> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Beginner Questions About XCB - xcb_alloc_color is too slow

[Ilya Anfimov]

On Sat, Feb 20, 2021 at 06:37:38PM -0800, Mark Solomonik wrote:
>Hello,

 Godd day.

[skipped]

>  Is this an appropriate way to set the color? Is there a more efficient way 
> to do so?

 Well, you have mostly good answers to this question.
 (I personally disagree with the one that recommended RENDER).
 Yes,  you should generally find r,g,b bitmasks and then just put
pixel values. AllocColor is practically useless on TrueColor  vi-
suals, and currently there is almost no other types.


> 
> 
>  Slightly unrelated question: as someone completely new to Xorg and Linux 
> graphics in general,
>  how do you deal with the lack of documentation for XCB?

 The documentation on protocol is an "X Window System Protocol"

https://www.x.org/releases/X11R7.5/doc/x11proto/proto.pdf

  Xlib and xcb are just C language bindings for the protocol.

> 
> 
>  Thanks,
> 
>  Mark

> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Where is the documentation for the clipboards?

[Ilya Anfimov]

On Tue, Jan 12, 2021 at 10:56:51PM -0800, ToddAndMargo wrote:
> Hi All,
> 
> I am not finding anything about the two clipboards over on
>    https://www.x.org/releases/current/doc/libX11/libX11/libX11.html
> 
> Is "clipboard" the wrong keyword to search for?

 1) The documentation for the X11 is the "X Window System Protocol"

https://www.x.org/releases/X11R7.5/doc/x11proto/proto.pdf

 not the "Xlib - C Language X Interface" .

 The latter relies heavily on knowledge of the former.

 2) Two clibpoard names (well, more in fact) is a convention about protocol
usage, described in the ICCCM

  https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html

  Also there are some practice described by fd.o specs and comments form this
links

  https://www.freedesktop.org/wiki/Specifications/ ,

  at least  https://www.irif.fr/~jch//software/UTF8_STRING/ and
  https://www.freedesktop.org/wiki/Specifications/clipboards-spec/


  I recommend to make some experiments (get targets, look which contains useful
data) with major toolkits and typical scenarios (non-ascii letters, files,
images) to be familiar with the ecosystem.



> 
> Also, are there any examples out there in C land on how to read
> and write to the two clipboards?
> 
> Many thanks,
> -T
> 
> -- 
> ~~
> Computers are like air conditioners.
> They malfunction when you open windows
> ~~
> 
> 
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Problem with X and JPEG2000 images

[Ilya Anfimov]

On Fri, Jan 01, 2021 at 10:12:13AM -0800, Alan Coopersmith wrote:
> On 1/1/21 5:37 AM, szukw000 wrote:
> > I use fltk-1.4 . Large images are not shown with LINUX:
> > 
> > image size: 811 792 452 Byte
> > 
> > ESP_028011_2055_RED.JP2(28260 x 52834)
> 
> The X11 coordinate space is defined as signed 16-bit numbers, so maxes
> out at 32767.  This is deeply embedded in the X11 protocol, and cannot
> be changed without revising the protocol to create X version 12, but

 Well, I disagree with this statement.

 I think that resolution could be "virtualised", so that old apps
would see some reasonably high definition screen with  some  more
or  less  fixed DPI or something like DPI (perhaps dots per radi-
an).
 While some extension would allow to obtain more  physical  pixel
properties  of  windows/screens  without  disturbing apps and li-
braries that stuck to an old two-dimensional 15-bit  coord  tris-
timulus  pixels,  and  to implement coordinate transformations to
draw  with  extended  resolution  on  existing  windows  or  even
pixmaps.

 It  is  just  not really necessary now, considering that even 8k
screens are really rare.

> the development community is putting it's efforts into Wayland instead
> now.
> 
> -- 
>   -Alan Coopersmith-   alan.coopersm...@oracle.com
>Oracle Solaris Engineering - https://blogs.oracle.com/alanc
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: bitmaps or no?

[Ilya Anfimov]

On Tue, Dec 01, 2020 at 07:36:20PM -0500, James K. Lowden wrote:
> I have a basic how-does-one question about scrolling text in a window.  
> 
> I have the beginnings of an application that reads troff ditroff output
> and renders it on-screen.   The underlying libraries are 
> 
>   -lGL  -lglut -lX11 -lXi -lXft -lfontconfig -lcairo -lfreetype
> 
> Let's say the rendering has room for improvement, and is already better
> than xman(1).  
> 
> My question is: how to scroll pages of text?  
> 
> The troff output is potentially many pages, and the user will want to
> scroll up and down, as he does, say, viewing the bash(1) manual in GNU
> less(1).  
> 
> Currently I open a cairo surface on the main window.  Scrolling a
> screen of text up one line would require ... something. I could erase
> the whole thing and start over with line 2 at the top, replacing line
> 1.  
> 
> An alternative, I think, is to render the whole document to a bitmap,
> and scroll the bitmap up and down using just X primitives.  That

 I  suggest  to  use  some pixmap (or perhaps pixmap-backed cairo
surface) reasonably larger than a window, but not a  whole  docu-
ment.  Simple scrolling would be rather fast (all the data is al-
ready rendered, you  should  just  copy  it  somehow  inside  one
pixmap),  and  you  could  draw the new areas off-screen somewhat
later.

 On the other side, a whole troff document with hundreds A4 pages
with  a  reasonable  200  dpi  resolution and 8-bit grayscale an-
tialiasing render -- may take more that a gig of RAM, causing un-
neccessary paging.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Different output between xrandr and xdpyinfo

[Ilya Anfimov]

On Wed, Nov 18, 2020 at 09:47:00AM +0800, l...@sunray.cn wrote:
>Hi 

 Good day. 

>I'm using hdmi and lvds with touch screen. But the touch screen can move
>the pointer between two monitors like the picture now.png.
>But I want my touch screen to be applied on lvds like I want.png
>So I follow arch wiki to set the configuration. But I found xrandr showed
>only one screen: 
>root@imx6qsabresd:~# xrandr  
> 
>Screen 0: minimum 240 x 240, current 1024 x 768, maximum 8192 x 8192
>DISP3 BG connected 1024x768+0+0 (normal left inverted right x axis y axis)
>0mm x 0mm
>   1024x768_60.00  59.92*+
>xdpyinfo showed two screens.
>Here is xdpyinfo's output and /etc/X11/xorg.conf
>Also, I found the HDMI screen's cursor is a cross(the same as  'X'). 
>How to solve these problems?
>Regards
>Mihan

 Well,  several  screens is a rather ancient attempt to resolving
multihead configurations. It is not well supported  by  apps  and
DEs now.

 Currently,  the  usual  way  is  a single (virtual) Screen, with
xrandr managing multiple monitors on it.
 In xorg.conf it is specified in a Display SubSection of a Screen
section.
 Some good examples can be found e.g. here:

   https://wiki.archlinux.org/index.php/Multihead

> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: How can i change xkb configuration ?

[Ilya Anfimov]

On Fri, Nov 06, 2020 at 01:06:42PM +0200, aprekates wrote:
> Greetings to all,
> 
> Trying to edit = /usr/share/X11/xkb/symbols in my debian system to add a
> workman layout variant to greek i noticed the warning to not edit those
> files. What is the recommended way to do that ?

 Add a new file there.

> 
> Thanks , chomwitt
> 
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: .XCompose convert a single character

[Ilya Anfimov]

On Thu, Jul 09, 2020 at 06:44:48PM +, Ajith R wrote:
> Hi All,
> 
> I am new to Linux. I am using Debian GNU Linux 10 with KDE 5.14.5.
> 
> I want to make a cutom keyboard layout for my mother tongue Malayalam 
> (Kerala, India). I have managed to write the layout (by modifying the 
> /usr/share/X11/xkb/symbols/in file and apparently it is working  ok. One 
> character in Malayalam U0D19 ??? is not used as such (except rarely when 
> referring to the character itself). It is used as conjuncts, mostly as its 
> geminate form. To get the geminate form one need to type UD019 ??? followed 
> by U0D4D ??? followed by UD019 ??? again to get ?. If I could get 
> every UD019 ??? converted to ?, it could save a lot of key press (1 
> in place of three). I learned that .XCompose is the place to do that. 
> However, my .XCompose is not working. Its current content is as below.
> 
> include "%L" 
> 
> : "?"

 Good day!

 I see that you have a lot of non-breaking spaces (0xC2 0xA0 in UTF8,
Unicode point A0)
e.g. betwen `include "%L"' and EOL and between <...> and :
 It could be the reason for parser failure.

 Haven't tried this yet, also this could be not the case
if that appeared only when copying .XCompose text to e-mail message.

 Also, try setting environment GTK_IM_MODULE to xim

GTK_IM_MODULE=xim
export GTK_IM_MODULE

somewhere in ~/.Xsession or so, or at least in a shell before
launching test app.
 The default GTK im module has some strange shortcomings
related to Compose sequences.


> 
> I also tried 
> 
> include "%L" 
> 
> : "QQ"
> 
> to see if the english characters would work, but to no avail.
> 
> I read here https://dominiko.livejournal.com/20206.html that something 
> similar was done, but couldn't really understand what I am doing wrong.
> 
> I am trying this forum after trying Debian mail list unsuccesfully.
> 
> My queries
> 
> 1) Does the .XCompose mechanism permit conversion of a single /multiple 
> charcter(s)  to a string without using Compose / dead keys?

 Yes.

> 2) If so, what is wrong with my .XCompose file?
> 3) If my specification of the .XCompose file is okay, how do I find out what 
> is wrong (and correct it)?

 Probably it is, apart from spacing.
 However, the bundled XCompose used hex unicode representation
for trigger strings (parts of specification before ":"), e.g.  --
so it could be safer to use them.

> 4) Does the xkbmap system directly permit output of a string when a single 
> key is pressed (without the help of .XCompose)?

 No.

> 
> 
> Thanks,
> ajith
> 
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Why does X11 generate an extra SHIFT when I press Shift+KP_1 ?

[Ilya Anfimov]

On Mon, Feb 17, 2020 at 08:34:47PM +0530, Sreyan Chakravarty wrote:
>I did post the unfiltered output but it got scrubbed.
>This is my unfiltered output:
>IT SEEMS THE MOMENT I PRESS KP_1 WITH SHIFT A RELEASE EVENT IS GENERATED
>FOR MY SHIFT KEY EVEN BEFORE THE KEY PRESS FOR KP_1 IS REGISTERED AND WHEN
>I RELEASE KP_1 A PRESS EVENT IS GENERATED.
>IT IS ALMOST AS IF MY XKB CONFIGURATION FORBIDS SHIFT+KP_1 NO MATTER WHAT
>I DO.

 Well, it is possible. However, there are may be other explanations:
  -- some strange intellectual behaviour of the hardware (keyboard itself).
  -- some keyboard switching applet, that uses XTest to do that.


 At least this have some logic! It somehow blocks Shift+KP1 by releasing
Shift before sending KP1.

 Next simple thing: could you provide xkb dump?

 xkbcomp "$DISPLAY" /tmp/dump.xkb

>KeyPress event, serial 30, synthetic NO, window 0x4e1,
>root 0x3ac, subw 0x0, time 753837, (164,561), root:(814,600),
>state 0x10, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
>XLookupString gives 0 bytes:
>XFilterEvent returns: False
> 
>KeyRelease event, serial 30, synthetic NO, window 0x4e1,
>root 0x3ac, subw 0x0, time 754303, (164,561), root:(814,600),
>state 0x11, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
>XLookupString gives 0 bytes:
>XFilterEvent returns: False
> 
>KeyPress event, serial 30, synthetic NO, window 0x4e1,
>root 0x3ac, subw 0x0, time 754305, (164,561), root:(814,600),
>state 0x10, keycode 87 (keysym 0xffb1, KP_1), same_screen YES,
>XLookupString gives 1 bytes: (31) "1"
>XFilterEvent returns: False
> 
>KeyRelease event, serial 30, synthetic NO, window 0x4e1,
>root 0x3ac, subw 0x0, time 754351, (164,561), root:(814,600),
>state 0x10, keycode 87 (keysym 0xffb1, KP_1), same_screen YES,
>XLookupString gives 1 bytes: (31) "1"
>XFilterEvent returns: False
> 
>KeyPress event, serial 30, synthetic NO, window 0x4e1,
>root 0x3ac, subw 0x0, time 754352, (164,561), root:(814,600),
>state 0x10, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
>XLookupString gives 0 bytes:
>XFilterEvent returns: False

[skipped]

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Why does X11 generate an extra SHIFT when I press Shift+KP_1 ?

[Ilya Anfimov]

On Sun, Feb 16, 2020 at 04:41:55PM +0530, Sreyan Chakravarty wrote:
>When I press 
>Shift+KP_1 why am I getting an extra Shift in my xev output ?
> 
>  50  Shift_L
>  87  KP_1
>  50  Shift_L
> 
>  I am running xev in the following format:
> 
>  xev | awk -F'[ )]+' '/^KeyPress/ { a[NR+2] } NR in a { printf "%-3s %s\n", 
> $5, $8 }'
> 
>  This is messing with my i3 configs. Where is the extra Shift coming from ? I 
> have disabled
>  autorepeat and I still get the same output. (xset r off)
> 
>  Keyboard Layout: English US Default
>  OS: Manjaro i3wm
>  Why is this happening?

 Can you post unfiltered xev output when you press and release theese keys?

 Well, this could be some misinterpretation of xev, as well as
some xkb internal processings. xev output should rule out the first variant.
> 
>--
>Regards,
>Sreyan Chakravarty

> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: 30-bit X session and programs requiring 24-bit depth

[Ilya Anfimov]

On Mon, Feb 17, 2020 at 04:01:35PM +0700, Antoine Martin wrote:
> On 17/02/2020 15:51, Ilya Anfimov wrote:
> > On Sat, Feb 15, 2020 at 12:32:15AM +0700, Antoine Martin wrote:
> >> On 14/02/2020 18:53, Marek Szuba wrote:
> >>> Hello,
> >>>
> >>> I do quite a lot of photo editing on my box and with both my monitors
> >>> and my graphics card (amdgpu) supporting 10-bit colour channels, I tend
> >>> to run X at colour depth 30. Unfortunately some software, most notably
> >>> programs using OpenGL it seems, refuse to run in this mode - presumably
> >>> (I have seen this mentioned as the reason of problems with 30-bit mode
> >>> under Windows when the first cards supporting it came out) because the
> >>> software assumes 8-bit alpha channel but with the frame buffer still
> >>> being only 32-bit it is only 2-bit. Seeing as there seem to be no way of
> >>> switching colour depth on the fly, the best I have been able to come up
> >>> with is two separate X sessions - one at depth 30 and one at 24.
> >>>
> >>> Is there, or perhaps will there be some way in the near future, to work
> >>> around this problem - either by increasing framebuffer BPP (tried it a
> >>> while ago but it didn't seem to accept anything more than 32), using a
> >>> virtual X server (tried using Xephyr but it complained about there being
> >>> no matching screen), or some other way I haven't thought of?
> >> If you don't mind the indirection this introduces:
> >> xpra start --start=xterm --attach=yes
> >> This will start your application (ie: xterm) on a 24-bit virtual
> >> framebuffer and display it on your local 30-bit display.
> > 
> >  And with software-only OpenGL.
> If you want accelerated OpenGL within the xpra session, use VirtualGL:
> https://xpra.org/trac/wiki/Usage/OpenGL
> ie:
> xpra start --start="vglrun xterm" --attach=yes
 

  If  virtualgl  could  be used -- then yes, but then there is no
need in xpra.
  virtualgl itself has some other thin moments.

> >  xpra itself is not really good at either proxying or accelerating
> > glx/dri.
> Xpra doesn't even attempt to do these things, that's not its job.

 Well, I don't agree with that either, but the result is the same.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: 30-bit X session and programs requiring 24-bit depth

[Ilya Anfimov]

On Fri, Feb 14, 2020 at 12:53:53PM +0100, Marek Szuba wrote:
> Hello,
> 
> I do quite a lot of photo editing on my box and with both my monitors
> and my graphics card (amdgpu) supporting 10-bit colour channels, I tend
> to run X at colour depth 30. Unfortunately some software, most notably
> programs using OpenGL it seems, refuse to run in this mode - presumably
> (I have seen this mentioned as the reason of problems with 30-bit mode
> under Windows when the first cards supporting it came out) because the
> software assumes 8-bit alpha channel but with the frame buffer still
> being only 32-bit it is only 2-bit. Seeing as there seem to be no way of
> switching colour depth on the fly, the best I have been able to come up
> with is two separate X sessions - one at depth 30 and one at 24.

 Well,  you  can  try to run it via virtualgl -- however, I'm not
sure it will be easy to share one videocard  between  two  server
simultaneously  -- i.e., make that no one of them will be sent to
background.

> 
> Is there, or perhaps will there be some way in the near future, to work
> around this problem - either by increasing framebuffer BPP (tried it a
> while ago but it didn't seem to accept anything more than 32), using a

 I'm not sure it is really a framebuffer size problem.

 Shouldn't  alpha  be  stripped  off when copying data to DAC-ac-
cessed areas anyway?
 Also, There was 16-bit  framebuffers,  no  problems  with  alpha
there  -- when all the framebuffer bits was filled with color in-
formation.

 Can you post glxinfo ?

 Also, it would be useful to debug opengl calls of failed apps --
but there are different available techniques for different opengl
drivers.


> virtual X server (tried using Xephyr but it complained about there being
> no matching screen), or some other way I haven't thought of?
> 
> Thank you in advance for your comments.
> 
> -- 
> MS
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: 30-bit X session and programs requiring 24-bit depth

[Ilya Anfimov]

On Sat, Feb 15, 2020 at 12:32:15AM +0700, Antoine Martin wrote:
> On 14/02/2020 18:53, Marek Szuba wrote:
> > Hello,
> > 
> > I do quite a lot of photo editing on my box and with both my monitors
> > and my graphics card (amdgpu) supporting 10-bit colour channels, I tend
> > to run X at colour depth 30. Unfortunately some software, most notably
> > programs using OpenGL it seems, refuse to run in this mode - presumably
> > (I have seen this mentioned as the reason of problems with 30-bit mode
> > under Windows when the first cards supporting it came out) because the
> > software assumes 8-bit alpha channel but with the frame buffer still
> > being only 32-bit it is only 2-bit. Seeing as there seem to be no way of
> > switching colour depth on the fly, the best I have been able to come up
> > with is two separate X sessions - one at depth 30 and one at 24.
> > 
> > Is there, or perhaps will there be some way in the near future, to work
> > around this problem - either by increasing framebuffer BPP (tried it a
> > while ago but it didn't seem to accept anything more than 32), using a
> > virtual X server (tried using Xephyr but it complained about there being
> > no matching screen), or some other way I haven't thought of?
> If you don't mind the indirection this introduces:
> xpra start --start=xterm --attach=yes
> This will start your application (ie: xterm) on a 24-bit virtual
> framebuffer and display it on your local 30-bit display.

 And with software-only OpenGL.
 xpra itself is not really good at either proxying or accelerating
glx/dri.



> The pixel depth upscaling will be done by your OpenGL driver, or failing
> that, in software.
> 
> The reverse is also possible, with a local display at 24-bit:
> xpra start --start=xterm --attach=yes --pixel-depth=30
> Runs the app on a 30 bit virtual display.
> Apparently, there are apps that require a 30-bit display to use GPU
> image processing and some users don't care if they don't actually see
> the extra bit depth when doing so.
> 
> Antoine
> 
> > 
> > Thank you in advance for your comments.
> > 
> 
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: How to start with X?

[Ilya Anfimov]

On Wed, Jan 22, 2020 at 06:26:32PM +0100, Emanuele Petriglia wrote:
> Hi!
> 
> I would like to learn how to create a C graphical application without
> using some toolkit for hobby. I know that there are two main libraries:
> Xlib and xcb. The first is old but has a lot of documentation, the
> second is newer but less documented than the first. So I was thinking to
> learn Xlib and then xcb.
> 
> I found this book about Xlib: "XLIB Programming Manual" of Adrian Nye
> published on 1994. I do not found any other recent book. Is it good to
> start with Xlib even is it old?

 Good day!

 The Xlib programming manual is a good book, but it is definitely
based on "X Window System Protocol" (X Consortium standard).
 There are a lot of direct and indirect  references  to  concepts
and  behavior,  described  in the protocol standard. In fact, the
"Xlib" book is very incomplete if viewed alone.

 So, I think, that it is better  to  read  protocol  standard  at
first.   There  is  no need to memorize byte values and structure
alignments, as the Xlib have a good constants and structures  for
that. But most concepts described only there.

 btw,  "proto" book (it is usually named proto.pdf or proto.ps in
X sources) is a good material even for those who write  apps  for
X11  using toolkits. As well as ICCCM book (Inter-Client Communi-
cations Conventions Manual).


___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Problem with mapping a key to multiple characters (Unicode + diacritic symbol)

[Ilya Anfimov]

On Tue, Apr 02, 2019 at 02:31:31PM +0200, Pierre-Luc Angles wrote:
> Dear Ilya, dear xorgers,
> 
> 
> launching env XMODIFIERS='' GTK_IM_MODULE=xim libreoffice in my terminal
> makes indeed my keyboard for Unicode characters + diacritics working but
> switching to my French keyboard (variant with Sun dead keys), the dead keys
> like the dead_circumflex does not work any more (I have to close LibreOffice
> and reopen it to make env XMODIFIERS='' GTK_IM_MODULE=xim libreoffice be
> ended). I have checked and this is also the case with the normal French
> keyboard azerty.
> 
> On the contrary, the dead keys works on the keyboard layout that I have
> mapped when env XMODIFIERS='' GTK_IM_MODULE=xim libreoffice is launched.
> 
> It is just a small problem but I would but helpfull to understand why some
> dead keys works and other not when env XMODIFIERS='' GTK_IM_MODULE=xim
> libreoffice is launched.

 A possible explanation is that you didn't added

include "%L"

 at the beginning of you ~/.XCompose.

 There could be other variants, though. If that does not helps --
it will be good to say exactly what are you typing with dead_cir-
cumflex,  what  is  the usual sequence of unicode characters is a
result of typing, what is your locale  name  and  what  xev  says
about your text.


___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Changing key repeat behaviour for individual xinput devices

[Ilya Anfimov]

On Thu, Mar 21, 2019 at 03:57:38PM +1000, Peter Hutterer wrote:
> On Mon, Mar 18, 2019 at 01:21:56PM +0300, Ilya Anfimov wrote:
> > On Fri, Mar 15, 2019 at 08:54:13AM +1000, Peter Hutterer wrote:
> > > On Wed, Mar 13, 2019 at 05:19:21PM +0100, Timo Paulssen wrote:
> > > > Hello xorgers,
> > > > 

[skipped]

> > 
> > > (setxkbmap and xkbcomp have deviceid options) but paging in *how* to 
> > > disable
> > > autorepeat through an xkb map is beyond my mental capabilities right now.
> > 
> >  Well, it should be possible to enable toggle of repeat by adding
> > including AccessX(full) compat (sometimes already enabled,  often
> > enabled  AccessX(basic) ) and assigning RepeatKeys_Enable to some
> > key.
> > 
> >  But this looks ridiculous -- to press some key when a user  just
> > wants to disable repeat.
> 
> yeah, but that's what we have tools for. setxkbmap -layout looks simple, but
> what it does under the hood is a lot more involved.
 
 Well,  I  had  meant not the xkbcomp complexicity (well, in fact
for me the setxkbmap is more difficult to understand as  it  adds
some  levels  of  indirection) -- but rather the result of chang-
ing repeat via keymap with some key combination.

> 
> >  And  no, xkbcomp doesn't have direct enabling of repeat or other
> > XKBSetControl, there is no such words in xkb files. Also  libxkb-
> > file,  which  xkbcomp  uses  for changing server parameters -- it
> > have fields in it's structures for that controls --  but  it  ex-
> > plicitly skips setting XKBSetControls:
> > srvmisc.c:
> > 
> > #ifdef NOTYET
> > if (!XkbSetControls(dpy,XkbAllControlsMask,xkb))
> > return False;
> > #endif
> > 
> >  It  seems like would be good to add -dev option to xset and xkb-
> > set (for xset -- also for mouse controls) and rate or  maybe  all
> > XKBSetControls controls to xinput.
> 
> xset uses core protocol requests only so a -dev option wouldn't make sense
> here. xkbset could take device ids but I'm not sure it still has an upstream.

 In  fact  no, xset changes repeat rate via xkb (there is no such
a control in core), so it is (optionally, but almost universally)
compiled with xkb support.

> xinput - sure, I'll take pull requests.

 OK, will try sometime in the future.

> 
> Cheers,
>Peter
>  
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Problem with mapping a key to multiple characters (Unicode + diacritic symbol)

[Ilya Anfimov]

On Tue, Mar 19, 2019 at 12:14:32AM +0100, Pierre-Luc Angles wrote:
> Thanks for your answers!
> 
> I do not have ideas if Ilya or Walter is right for the configuration of
> /etc/profile... Do others have an idea?

 Don't take it too seriously.
 It really doesn't matter.


___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Problem with mapping a key to multiple characters (Unicode + diacritic symbol)

[Ilya Anfimov]

On Mon, Mar 18, 2019 at 05:25:43PM +0100, Walter Harms wrote:
> 

[skipped]

> > prompt  to  modify that for anything started later from that com-
> > mand prompt window.
> > 
> 
> 
> please note that /etc/profile is the system-wide profile. 
> do not change that.

 I think this could be exactly the reason to do so!

> 
> 
> re,
>  wh
> > ___
> > xorg@lists.x.org: X.Org support
> > Archives: http://lists.freedesktop.org/archives/xorg
> > Info: https://lists.x.org/mailman/listinfo/xorg
> > Your subscription address: %(user_address)s
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Problem with mapping a key to multiple characters (Unicode + diacritic symbol)

[Ilya Anfimov]

On Mon, Mar 18, 2019 at 03:56:16PM +0100, Pierre-Luc Angles wrote:
> Dear Ilya, dear ??en, dear all,
> 
> Thanks for your messages.
> 
> The font that I am using with this keys is Junicode.
> 
> A big thank you to Ilya!!! In my terminal, I have entered
> env XMODIFIERS='' GTK_IM_MODULE=xim libreoffice
> LibreOffice opens and I can type all the compose keys that I have entered in
> ~/.XCompose  I am very very glad! Thanks again Ilya!
> 
> Is there a way to automate this command or should I launch it every time I
> want to use these commands? Or is it "dangereous" somehow to have these
> commands configured like this all the time?

 It is usual environment variables.

 you can put

XMODIFIERS=''
export XMODIFIERS
GTK_IM_MODULE=xim
export GTK_IM_MODULE

somewhere in your ~/.xsessionrc

Probably  this  will stop im-config from modifying anything later
in Xsession processing, but all other  toolkits  should  be  just
fine with default values.

 You can add others the same way manually, however, something like:

QT_IM_MODULE=xim
export QT_IM_MODULE
QT4_IM_MODULE=xim
export QT4IM_MODULE
CLUTTER_IM_MODULE=xim
export CLUTTER_IM_MODULE


Also,  there  are  numerous ways to set your environment: you can
put it in /etc/profile, in ~/.profile, or  type  in  you  command
prompt  to  modify that for anything started later from that com-
mand prompt window.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Problem with mapping a key to multiple characters (Unicode + diacritic symbol)

[Ilya Anfimov]

On Thu, Mar 14, 2019 at 07:42:14PM +0100, Pierre-Luc Angles wrote:
> Dear Ilya, dear all,
> 
> Thanks again.
> 
> My full xkb mapping is the following. I have not added all the Compose keys
> but just i_breve_below to test it (note that it is not a i without dot but a
> normal i with a breve below and that the i withoutdot is combined with a
> half ring above.

 Good day.

 I  checked  some  other things, not your mapping and found some-
thing interesting:


  I've  forgotten  that I did rebuild libreoffice with --disable-
gtk --disable-gtk3  , and therefore without vclplug at all.

 Then I've found a  gtk2  libreoffice  version,  and  some  other
gtk2-gtk3 apps and nothing works there!

 Some investigation shows that im-config package sets

XMODIFIERS='@im=uim'

 environment  variable and  this breaks GTK IM completely. Unset-
ting XMODIFIERS or setting XMODIFIERS='' does  something  better,
but the default IM handling in the GTK is also completely broken:
it  doesn't support XKeysymDB, and doesn't support multiple  sym-
bols  result  per  mapping  and  also  always  reads  in  default
/usr/share/.../Compose file like

  include "%L"

is added at the begining of ~/.XCompose

 But  setting GTK_IM_MODULE=xim fixes that problems (after unset-
ting XMODIFIERS !)

so, env XMODIFIERS='' GTK_IM_MODULE=xim libreoffice may work  for
you.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Changing key repeat behaviour for individual xinput devices

[Ilya Anfimov]

On Fri, Mar 15, 2019 at 08:54:13AM +1000, Peter Hutterer wrote:
> On Wed, Mar 13, 2019 at 05:19:21PM +0100, Timo Paulssen wrote:
> > Hello xorgers,
> > 
> > I recently got a small bluetooth keyboard. I'd like to try to use it as
> > a secondary keyboard for things like shortcuts, but my first experiment
> > was to turn it into a midi keyboard with a combination of PortMIDI and
> > xinput float + xinput test. Unfortunately, it has a pretty aggressive
> > key repetition rate set up.
> > 
> > The right way to fix this would normally be xset, but IIUC that'd change
> > the behavior of all connected keyboards. xinput has a flag
> > --get-feedbacks that gets me an XkbdFeedbackClass with
> > "global_auto_repeat" and percent/pitch/duration properties. I'd assume
> > that's the right thing to change, but it looks like the only classes
> > xinput's commandline utility lets me change are ptr-feedback and
> > integer-feedback, which seems to be about acceleration and scaling or
> > something like that?
> > 
> > Will I have to write a little snippet of C to change these particular
> 
> there is/was an "xkbset" utility, not sure if that supports per-device flags
> though. there's also the option of setting a custom keymap for that device

 It doesn't.
 I had checked xset, xkbset, xinput, xkbcomp -- all of them either
don't have global rate controls or are using core device.


> (setxkbmap and xkbcomp have deviceid options) but paging in *how* to disable
> autorepeat through an xkb map is beyond my mental capabilities right now.

 Well, it should be possible to enable toggle of repeat by adding
including AccessX(full) compat (sometimes already enabled,  often
enabled  AccessX(basic) ) and assigning RepeatKeys_Enable to some
key.


 But this looks ridiculous -- to press some key when a user  just
wants to disable repeat.

 And  no, xkbcomp doesn't have direct enabling of repeat or other
XKBSetControl, there is no such words in xkb files. Also  libxkb-
file,  which  xkbcomp  uses  for changing server parameters -- it
have fields in it's structures for that controls --  but  it  ex-
plicitly skips setting XKBSetControls:
srvmisc.c:

#ifdef NOTYET
if (!XkbSetControls(dpy,XkbAllControlsMask,xkb))
return False;
#endif




 It  seems like would be good to add -dev option to xset and xkb-
set (for xset -- also for mouse controls) and rate or  maybe  all
XKBSetControls controls to xinput.


___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Problem with mapping a key to multiple characters (Unicode + diacritic symbol)

[Ilya Anfimov]

On Thu, Mar 14, 2019 at 02:04:11PM +0100, Pierre-Luc Angles wrote:
> Dear Ilya, dear all,
> 
> thanks again for your answers.
> 
> Without knowing if this is the good direction, I have tested to change
> ~/.XCompose by typing first the diacritic and then the "diacriticised"
> letter, but it does not make differences in LibreOffice and in Firefox. Note
> that when I type AltGr+& in Firefox, it remains an ampersand whereas in
> LibreOffice it appears as nothing and does not react.

 Shouldn't   work:   I   had  tested  it  with  LO  and  assigned
 to KP_Multiply, with your ~/.XCompose string, and
it typed OK and i without a dot and with a breve below.

 Well,  it should just work another way: adding breve to previous
symbol and typing i without a dot.

[skipped]

PS Well... AltGr... or LevelThree... I have never seen a  working
setup  with that keys so far. Not sure even how it is supposed to
work (isn't Alt* is invoking menu action in most toolkits?). Per-
haps, adding your full xkb mapping may somewhat advance our stud-
ies.



___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Problem with mapping a key to multiple characters (Unicode + diacritic symbol)

[Ilya Anfimov]

On Wed, Mar 13, 2019 at 03:20:00PM +0100, Pierre-Luc Angles wrote:
> Dear Ilya, dear all,
> 
> now I have tried once again in my keyboard layout
> 
> key { [ampersand,1,
>  i_breve_below,   U032F ] };
> 
> Typing it in a LibreOffice document with the right font results in no
> reaction (whereas before it reacts like NoSymbol by putting the default
> onesuperior).

 Did  you  restarted  libreoffice completely? I mean, closing any
window and checking that no "quickstart" is hanging in memory?
 XKeysymDB and *Compose are read only once at startup.

> 
> Running xev I can see now:
> 
> KeyPress event, serial 37, synthetic NO, window 0x4c1,
> root 0x168, subw 0x0, time 2807193, (-519,30), root:(568,309),
> state 0x4090, keycode 0 (keysym 0x0, NoSymbol), same_screen YES,
> XLookupString gives 0 bytes:
> XmbLookupString gives 3 bytes: (69 cc af) "i??"
> XFilterEvent returns: False

 It's probably the second event after that keypress.
 And  this  is  the usual xlib compose path: real keypresses that
are part of composing sequences (or can be such a part)  reported
as  usual,  except  that XFilterEvent returns True, after receiv-
ing a complete sequence (or getting something that is  definitely
not a beginning of a sequence) an event  with the keycode 0 simu-
lated that returns final string via  XmbLookupString.

> 
> KeyRelease event, serial 37, synthetic NO, window 0x4c1,
> root 0x168, subw 0x0, time 2807315, (-519,30), root:(568,309),
> state 0x4090, keycode 10 (keysym 0x100050f5, i_breve_below), same_screen
> YES,
> XLookupString gives 0 bytes:
> XFilterEvent returns: False
> 
> KeyRelease event, serial 37, synthetic NO, window 0x4c1,
> root 0x168, subw 0x0, time 2810008, (-519,30), root:(568,309),
> state 0x4090, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen
> YES,
> XKeysymToKeycode returns keycode: 92
> XLookupString gives 0 bytes:
> XFilterEvent returns: False
> 
> Note that a working key typed with the ALtGr modifier on the same keyboard
> layout has just two paragraphs in xev, for example:

 This  doesn't seems to use Compose. Just a usual unicode symbol,
directly translated (0x0101  in   Unicode   is   0xc4   0x81   in
utf8).

> 
> KeyPress event, serial 37, synthetic NO, window 0x4c1,
> root 0x168, subw 0x0, time 2802465, (-519,30), root:(568,309),
> state 0x4090, keycode 24 (keysym 0x1000101, U0101), same_screen YES,
> XLookupString gives 2 bytes: (c4 81) "??"
> XmbLookupString gives 2 bytes: (c4 81) "??"
> XFilterEvent returns: False
> 
> KeyRelease event, serial 37, synthetic NO, window 0x4c1,
> root 0x168, subw 0x0, time 2802581, (-519,30), root:(568,309),
> state 0x4090, keycode 24 (keysym 0x1000101, U0101), same_screen YES,
> XLookupString gives 2 bytes: (c4 81) "??"
> XFilterEvent returns: False
> 
> 
> It seems then to be the good direction, so thank you but I do not see what I
> could do now.
> 
> Thanks again!
> 
> Best,
> 
> Pierre-Luc
> 
> Le 13/03/2019 ?? 15:04, Pierre-Luc Angles a ??crit :
> > Dear Ilya, dear all,
> > 
> > Thanks again for this important remark.
> > 
> > My ~/.XCompose file is then the following:
> > 
> >  : "i??"
> >  : "u??"
> >  : ""
> >  : "I??"
> >  : ""
> >  : ""
> >  : "s??"
> >  : "S??"
> >  : "H??"
> >  : "h??"
> >  : "H??"
> > 
> > My /usr/share/X11/XKeysymDB is the following:
> > 
> > i_breve_below    :100050F5
> > u_breve_below    :100050F6
> > i_wtdot_ring_above    :100050F7
> > I_ring_above    :100050F8
> > c_caron_dot_below    :100050F9
> > C_caron_dot_below    :100050FA
> > s_macron_below    :100050FB
> > S_macron_below    :100050FC
> > H_macron_below    :100050FD
> > h_circumf_below    :100050FE
> > H_circumf_below    :100050FF
> > 
> > and in my keyboard layout I have tried in a first time with:
> > 
> > 
> > key     { [    ampersand,    1,
> > i_breve_below,   U032F ] };
> > 
> > and afterwards i a second time with
> > 
> > key     { [    ampersand,    1,
> > U100050F5,   U032F ] };
> > 
> > The keyboard is working but the i_breve_below or U100050F5 is not
> > working (I still have this xev when I type on the ampersand key + the
> > AltGr modifier:
> > 
> > KeyRelease event, serial 37, synthetic NO, window 0x4e1,
> >      root 0x168, subw 0x0, time 2120434, (-409,14), root:(142,282),
> >      state 0x4090, keycode 10 (keysym 0xb9, onesuperior), same_screen YES,
> >      XKeysymToKeycode returns keycode: 49
> >      XLookupString gives 2 bytes: (c2 b9) "??"
> >      XFilterEvent returns: False
> > 
> > I do not see where the problem is now...
> > 
> > It could be helpful if some one has a key.
> > 
> > Thanks again and sorry for bothering you with that.
> > 
> > Best,
> > 
> > Pierre-Luc
> ___
> xorg@lists.x.org: X.Org support
> Archive

Re: Problem with mapping a key to multiple characters (Unicode + diacritic symbol)

[Ilya Anfimov]

On Wed, Mar 13, 2019 at 03:04:17PM +0100, Pierre-Luc Angles wrote:
> Dear Ilya, dear all,
> 
> Thanks again for this important remark.
> 
> My ~/.XCompose file is then the following:
> 

[skipped]

> 
> key { [ampersand,1,  i_breve_below,
> U032F ] };
> 
> and afterwards i a second time with
> 
> key { [ampersand,1,U100050F5,   
> 
> U032F ] };

 Well,  U100050F5 shouldn't work at all, as there is a maximum of
U10 for unicode keysyms. You have to type 0x100050F5  if  you
want direct a number.
 i_breve_below,  however,  should.  But I had read your next mes-
sage, and it works, so it is OK.

> 
> The keyboard is working but the i_breve_below or U100050F5 is not working (I
> still have this xev when I type on the ampersand key + the AltGr modifier:
> 
> KeyRelease event, serial 37, synthetic NO, window 0x4e1,
> root 0x168, subw 0x0, time 2120434, (-409,14), root:(142,282),
> state 0x4090, keycode 10 (keysym 0xb9, onesuperior), same_screen YES,
> XKeysymToKeycode returns keycode: 49
> XLookupString gives 2 bytes: (c2 b9) "??"
> XFilterEvent returns: False
> 
> I do not see where the problem is now...
> 
> It could be helpful if some one has a key.
> 
> Thanks again and sorry for bothering you with that.
> 
> Best,
> 
> Pierre-Luc
> 
> Le 13/03/2019 ?? 11:56, Ilya Anfimov a ??crit :
> >   (Well,  I'm suspecting that I shouldn't disorient your work with
> > that comment about numerology and last numbers).
> > 
> >   I'd better take something like 0x10005001 - 0x100050FF
> > 
> >   Also, 8-bit was about character names -- your  fancy
> > i without dot  and  c with caron, better spell keysyms
> > with it like i_without_dot_ring_above and c_with_caron_dot_below,
> > and not include  unicode symbols with values over 0x7F
> > in keysym names.
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Problem with mapping a key to multiple characters (Unicode + diacritic symbol)

[Ilya Anfimov]

On Wed, Mar 13, 2019 at 11:37:51AM +0100, Pierre-Luc Angles wrote:
> Dear Ilya, dear all,
> 
> Thanks for your quick and nice answer. So would you recommend me to use, for
> my XKeysymDB file, 7bit characters (e.g. 185 to 18F) instead of the
> last positions of allowed ones (i.e. 8bit characters 1FF5 to 1FFF)
> or would recommend other positions like private use area Unicode (for
> example F8F5 to F8FF) ?

 (Well,  I'm suspecting that I shouldn't disorient your work with
that comment about numerology and last numbers).

 I'd better take something like 0x10005001 - 0x100050FF

 Also, 8-bit was about character names -- your  fancy
i without dot  and  c with caron, better spell keysyms
with it like i_without_dot_ring_above and c_with_caron_dot_below,
and not include  unicode symbols with values over 0x7F
in keysym names.

> 
> Thanks again and sorry if my question is too "easy".
> 
> Best,
> 
> Pierre-Luc
> 
> Le 13/03/2019 ?? 09:00, Ilya Anfimov a ??crit :
> > > 
> > > Le 12/03/2019 ?? 15:16, Ilya Anfimov a ??crit :
> 
> > > i_breve_below etc. are indeed names that I have created and as you rightly
> > > wrote, I should add them to /usr/include/X11/keysymdef.h
> 
> >   Well, better don't. You would need to recompile at least libX11
> > after that, and support your forked binary on every
> > system you use.
> >   However, you got the simpler way below:
> > 
> 
> > 
> > > So I assume that I have to create a XKeysymDB file in /usr/share/X11/ that
> > > would be the following:
> > > 
> > > i_breve_below :1FF5
> etc.
> > > H_circumf_below   :1FFF
> >   Yes, I think it should work. Not checked yet.
> >   I'm not sure about using 8bit characters in names though. Better
> > stick to naming it in ascii-7.
> >   Also, I personally would be a bit afraid  of  taking  specially-
> > looking  range like the last positions of allowed ones, but it is
> > definitely legal.
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Problem with mapping a key to multiple characters (Unicode + diacritic symbol)

[Ilya Anfimov]

On Wed, Mar 13, 2019 at 12:46:25AM +0100, Pierre-Luc Angles wrote:
> Dear Ilya,
> 
> Thanks a lot for your interesting advices.
> 
> Le 12/03/2019 ?? 15:16, Ilya Anfimov a ??crit :
> > You are probably right. Keysyms does not get added automatically
> > by naming it, and I don't see any mention of i_breve_below and so
> > on  in  standard keysymdef.h , which is the source of the default
> > set of keysyms.
> 
> i_breve_below etc. are indeed names that I have created and as you rightly
> wrote, I should add them to /usr/include/X11/keysymdef.h

 Well, better don't. You would need to recompile at least libX11
after that, and support your forked binary on every
system you use.
 However, you got the simpler way below:


[skipped]

> 
> So I assume that I have to create a XKeysymDB file in /usr/share/X11/ that
> would be the following:
> 
> i_breve_below :1FF5
> u_breve_below :1FF6
> ??_ring_above :1FF7
> I_ring_above  :1FF8
> ??_dot_below  :1FF9
> ??_dot_below  :1FFA
> s_macron_below:1FFB
> S_macron_below:1FFC
> H_macron_below:1FFD
> h_circumf_below   :1FFE
> H_circumf_below   :1FFF

 Yes, I think it should work. Not checked yet.
 I'm not sure about using 8bit characters in names though. Better
stick to naming it in ascii-7.
 Also, I personally would be a bit afraid  of  taking  specially-
looking  range like the last positions of allowed ones, but it is
definitely legal.

[skipped]

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Problem with mapping a key to multiple characters (Unicode + diacritic symbol)

[Ilya Anfimov]

On Mon, Mar 11, 2019 at 07:11:33PM +0100, Pierre-Luc Angles wrote:
> Dear list-members,
> 
> I allow me to write to you because I am now creating / mapping two different
> keyboard layouts, one for the transliteration of Ancient Egyptian and the
> other for a special Greek polytonic keyboard used by people reading ancient
> Greek documents. I have problems with these two new keyboards.
> 
> First, I would like to solve my problem with the transliteration of Ancient
> Egyptian.
> 
> I read in the archive of this list this thread (cf.
> https://lists.freedesktop.org/archives/xorg/2009-January/042282.html) and
> that is why I have created a file ~/.XCompose, with contents
> 
>  : "i??"
>  : "u??"
>  : ""
>  : "I??"
>  : ""
>  : ""
>  : "s??"
>  : "S??"
>  : "H??"
>  : "h??"
>  : "H??"
> 
> When I modify for example my keyboard layout like this
> :
> 
> key { [ampersand,1,i_breve_below,   
> 
> U032F ] };
> 
> the i_breve_below does not work and function, I think, as if it would be
> ???NoSymbol??? instead of this.

 You are probably right. Keysyms does not get added automatically
by naming it, and I don't see any mention of i_breve_below and so
on  in  standard keysymdef.h , which is the source of the default
set of keysyms.

 You can always check it by running xev and pressing that key  in
it's window. It should display NoSymbol, AFAIK.

 If you really want your keysym -- you can probably add one.  You
need to define a value for that keysym, probably in  the  vendor-
specific  range #x1000..#x1FFF  (29th bit set). Also note
already used ones, you can get it from the  last  used  XKeysymDB
file:


https://gitlab.freedesktop.org/xorg/lib/libx11/blob/00175397480b76d32bf82b0c7c94c91a2a95954e/src/XKeysymDB

Also  note,  that  #x1100 to #x1100 are reserved for key-
pad, so don't use that either.


 Then you can write your new XKeysymDB in the same format as  ex-
ample  above  and put it the /usr/share/X11 on every machine that
needs to work with your keys.
 Well, the /usr/share/X11/XKeysymDB is the place that my  current
devuan  expects  it to be, and other distributions can place this
file in other places, like /usr/X11R6/lib/ or so. You can quickly
find an exact place by running

  strace xkbcomp "$DISPLAY"  - 2>&1 >/dev/null  |grep XKeysym

  (if you have strace, of course).

 Then  reloading  your xkb should work, and .XCompose should work
also.

 Or you can type any keysym number in-place just by  typing  it's
code in hex with 0x prefix as in 0x1501

 However,  it  can  be  simpler to borrow some unused or reserved
unicode position, as every unicode character in the  range  0x100
--  0x10 have a default assigned keysym name "Uxxx", e.g. the
cyrillic capital letter A (0x410 unicode value) would  be  keysym
"U410"  and  first private use area symbol (0xE000 unicode value)
would be keysym "UE000".

> 
> For information, I am using Linux Manjaro 4.19 XFCE and scim is not enabled
> and not downloaded on my laptop.
> 
> I would be very nice if you could me help somehow to solve this problem.
> 
> I thank you in advance a lot.
> 
> Best regards,
> 
> Pierre-Luc
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: [devel] XLFD font naming convention

[Ilya Anfimov]

On Mon, Mar 04, 2019 at 07:03:00PM +0100, Lucien Gentis wrote:
>Le 04/03/2019 `a 18:18, Ilya Anfimov a ecrit :
> 

[skipped]

> 
> "For a scalable font source, a scalable font name for each
> character set is included in the list.  In addition to
> the scalable font name, specific derived instance names
> may also be included in the list."
> ...
> "Because some existing applications rely on seeing a collection
> of point and pixel sizes, server vendors are strongly
> encouraged in the near term to provide a mechanism for
> including, for each scalable font name, a set of specific
> derived instance names. For font sources that contain a set of
> specific derived instance names."
> 
>So  it  is OK to have that in font list. It must be --0-0-  base
>  name for every such font, and if it is not -- there is  an  error
>  somewhere in your X server or font server, and probably should be
>  fixed. If there are base entries -- then you  don't need them.
> 

[skipped]

> 
>I don't really need it, existing choice is big enough !
> 

 Probably you somewhat misread my description.
 It  should  be  not big enough, it should contain all that fonts
with proper fields zeroed.
 If it does not -- it is some error in server.



>But I only wanted to know the signification of "0" field in -adobe-new
>century schoolbook-bold-r-normal--0-120-100-100-p-0-iso10646-1
> 
>I did these (easy to reproduce) tests with xfontsel and xlsfonts commands
>:
> 
>xfontsel :
> 
>- if we select a point size of 120, it's impossible to select a pixel size
>of 0
> 
>- if we select a pixel size of 0, we only have the choice between * or 0
>for point size
> 
>xlsfonts :
> 
>- xlsfonts -fn "-*-*-*-*-*-*-0-*-*-*-*-*-*-*" (pixel size of 0) : we can
>see scalable fonts and fonts like -adobe-new century
>schoolbook-bold-r-normal--0-120-100-100-p-0-iso10646-1
> 
>- xlsfonts -fn "-*-*-*-*-*-*-0-120-*-*-*-*-*-*" (pixel size of 0, point
>size of 120) : we can see fonts like -adobe-new century
>schoolbook-bold-r-normal--0-120-100-100-p-0-iso10646-1
> 
>- xlsfonts -fn "-*-*-*-*-*-*-*-120-*-*-*-*-*-*" (point size of 120) :we
>don't see anymore fonts like -adobe-new century
>schoolbook-bold-r-normal--0-120-100-100-p-0-iso10646-1, which is confusing
>because "-*-120-" also matches "-0-120-"
> 
> 
>  ___
>  xorg@lists.x.org: X.Org support
>  Archives: http://lists.freedesktop.org/archives/xorg
>  Info: https://lists.x.org/mailman/listinfo/xorg
>  Your subscription address: %(user_address)s

> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: [devel] XLFD font naming convention

[Ilya Anfimov]

On Mon, Mar 04, 2019 at 05:29:10PM +0100, Lucien Gentis wrote:
> 
> Le 04/03/2019 ?? 16:20, Ilya Anfimov a ??crit :
> > On Fri, Mar 01, 2019 at 06:09:02PM +0100, Lucien Gentis wrote:

[skipped]

> > > 
> > > we get scalable fonts with fields 7,8,12 at "0" like :
> > > 
> > > -bitstream-charter-medium-i-normal--0-0-75-75-p-0-iso8859-1
> > > -dec-terminal-medium-r-normal--0-0-75-75-c-0-dec-dectech
> > > 
> > > but if we call :
> > > 
> > > XListFonts(serveur, "-*-*-*-*-*-*-0-*-*-*-*-*-*-*", 1, &nbFonts);
> > > 
> > > we also get fonts with only field 7 at "0" like :
> > > 
> > > -bitstream-charter-bold-r-normal--0-120-100-100-p-0-iso8859-1
> > > -adobe-new century schoolbook-bold-r-normal--0-120-100-100-p-0-iso10646-1
> > > 
> > > what about these fonts ?
> >   Well, X Logical Font Description Conventions
> >  Version 1.5
> > says (section 5):
> > 
> >"For a scalable font source, a scalable font name for each
> >character set is included in the list.  In addition to
> >the scalable font name, specific derived instance names
> >may also be included in the list."
> >...
> >"Because some existing applications rely on seeing a collection
> >of point and pixel sizes, server vendors are strongly
> >encouraged in the near term to provide a mechanism for
> >including, for each scalable font name, a set of specific
> >derived instance names. For font sources that contain a set of
> >specific derived instance names."
> > 
> >   So  it  is OK to have that in font list. It must be --0-0-  base
> > name for every such font, and if it is not -- there is  an  error
> > somewhere in your X server or font server, and probably should be
> > fixed. If there are base entries -- then you  don't need them.
> But how to determine if a font is scalable or not when its fields 7, 8 and
> 12 are not at "0" ?

 Why do you need it?
 Usually you can safely assume, that this font is not scalable.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: [devel] XLFD font naming convention

[Ilya Anfimov]

On Fri, Mar 01, 2019 at 06:09:02PM +0100, Lucien Gentis wrote:
> Hi,
> 
> When in an X application, we call (with 14 fields) :
> 
> XListFonts(serveur, "-*-*-*-*-*-*-0-0-*-*-*-0-*-*", 1, &nbFonts);
> 
> we get scalable fonts with fields 7,8,12 at "0" like :
> 
> -bitstream-charter-medium-i-normal--0-0-75-75-p-0-iso8859-1
> -dec-terminal-medium-r-normal--0-0-75-75-c-0-dec-dectech
> 
> but if we call :
> 
> XListFonts(serveur, "-*-*-*-*-*-*-0-*-*-*-*-*-*-*", 1, &nbFonts);
> 
> we also get fonts with only field 7 at "0" like :
> 
> -bitstream-charter-bold-r-normal--0-120-100-100-p-0-iso8859-1
> -adobe-new century schoolbook-bold-r-normal--0-120-100-100-p-0-iso10646-1
> 
> what about these fonts ?

 Well, X Logical Font Description Conventions
Version 1.5
says (section 5):

  "For a scalable font source, a scalable font name for each
  character set is included in the list.  In addition to
  the scalable font name, specific derived instance names
  may also be included in the list."
  ...
  "Because some existing applications rely on seeing a collection
  of point and pixel sizes, server vendors are strongly
  encouraged in the near term to provide a mechanism for
  including, for each scalable font name, a set of specific
  derived instance names. For font sources that contain a set of
  specific derived instance names."

 So  it  is OK to have that in font list. It must be --0-0-  base
name for every such font, and if it is not -- there is  an  error
somewhere in your X server or font server, and probably should be
fixed. If there are base entries -- then you  don't need them.

> 
> It's told in doc that scalable fonts must have their fields 7, 8 and 12 at
> "0"
> 
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: XORG and Dummy driver compatible with Android

[Ilya Anfimov]

On Mon, Nov 19, 2018 at 10:58:00AM +0100, Mgr. Janusz Chmiel wrote:

 Good day.

> Dear MR Anfimov,
> Thank you very much for yours professional support.
> But I AM sad, that external keyboard may be could not be used from AN x
> running app.

 Cannot say much about keyboard support in Xvfb. In general, key-
board would be disabled by default, but anything Xorg can support
can  be enabled in config.
 I don't know whether this android port supports any keyboard in-
put from android libraries...


> When I will type
> export DISPLAY=:0
> on Debian executed by using Proot, do you think, that Debian would be able
> to communicate with Xserver whichwill run on Termux?

 I  have  never used Proot, so don't know exactly. The DISPLAY=:0
requires common /tmp directory -- if it is,  then  probably  yes,
this will work.

 Anyway,  if  DISPLAY=:0  is  not usable -- you always can enable
tcp/ip (remove -nolisten tcp from startup scripts) and connect to
127.0.0.1:0


___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: XORG and Dummy driver compatible with Android

[Ilya Anfimov]

On Wed, Nov 14, 2018 at 04:13:00PM +0100, Mgr. Janusz Chmiel wrote:
> Please does somebody of us know if there is AN hack, which will allow Me to
> run X11 based apps on Android operating system, which would use XORG as X
> server?
> I have heart, that booting Linux kernel directly from SD cart for example
> from rooted Android device can cause touching display damage if somebody
> will try to run startx command from rooted system, because XORG perhaps uses
> some monitor calibration, which may be can damage touching display on
> Android devices.
> Because I do not see at all, display output quality or usability is not
> important for Me. I only need that communication between app and XORG will
> run at software level.
> Or is it not possible?

 Good day. In a fresh termux, there is an x11-repo package,
that adds a repository https://termux-x11.ml with X tools and libraries.

 There is xorg-server-xvfb package, with the Xvfb binary,
that does exactly what you want.

 (Note: as usual, openssl dependency was forgotten there.
Install and/or upgrade openssl to run it).

> I can use Orca screen reader and several GTK apps at The same time thanks to
> Proot, Termux. But I would be much more happy, if I would be able to use
> native Linux XORG instead of complex communication between Xserver XSDL
> which run on Android native C code and Termux session.
> Some instructions are very welcomed.
> I can use Xserver for ARMHF or for ARM64 CPu architectures.
> Thank you very much for yours advices.
> 
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Fwd: Indirect GLX still broken

[Ilya Anfimov]

On Thu, Jun 14, 2018 at 06:02:07AM +0100, Steve Dodd wrote:
>On 12 June 2018 at 10:45, Ilya Anfimov  wrote:
> 
>  The GLX pathway had too many data copy-ing, that process wass 
> 
>  too CPU-based and sycnhronous, also it had some  optimisations 
> 
>of  packing  and pipelining drawcalls in one write() syscall, [..]
> 
>I was thinking about this .. what happened to the AIGLX pathways that were
>originally added in mainly for compositing window managers? Is that all
>now done directly using DRI2 for local clients?

 It  worked  unitl  GLX  was  removed. Probably, minor fixing GLX
would also enable AIGLX, AFAIK code was not removed.

 However, compositing window managers had relatively small number
of  drawcalls  (somtehing like O(number of windows)), mostly tex-
turing of large surfaces, based on something already in X  server
memory.

 glx was not a show-stopper for them. Texturing in software, how-
ever, was -- as it overpaints a screen several  times,  therefore
AIGLX acceleration with simple forwarding was an advancement.

>Still intrigued by VirtualGL and it's making me try to understand current
>X architecture better. I didn't realise quite how complicated it had got.
>S.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Fwd: Indirect GLX still broken

[Ilya Anfimov]

On Tue, Jun 12, 2018 at 10:29:38AM +0100, Steve Dodd wrote:
>On 12 June 2018 at 10:08, Ilya Anfimov <[1]i...@tzirechnoy.com> wrote:
> 
>   No, currently there is no developers willing to improve this.
>   However, you can try some proxies like virtualgl.
> 
>Is there any understanding of the root of the problem? In theory I could
>start looking into it, but I'm old and ill and very out-of-date on modern
>technologies like git :)

 Well,  the  code  was disabled when it was found a lot of buffer
overflows.
 Currently, it requires thorough analysis and fixing of security-
related weaknesses.
 Hoewer, it was easily droppped beacause it was barely usable:
  current  usage  patterns requires a lot of interactions with GL
subsystem, many of them transferring (or sometimes just  pointing
to) a huge amount of data, with some assumed synchronizations. It
was barely compatible with 20-year old code of sockets-based  in-
terprocess  comuncation.  The GLX pathway had too many data copy-
ing, that process wass too CPU-based and sycnhronous, also it had
some  optimisations  of  packing  and pipelining drawcalls in one
write() syscall, which was essential for performance but  created
awful buffering issues for unaware application and hardware.
(Like buffering data for 15 seconds of rendering. Not
exciting at all for gaming!)

 So, probably it can be enabled after security analysis, but have
to be reengineered after that to be useful.

>I currently have quite a lot on my plate, but will at some point try roll
>backing to earlier versions, etc. as has been done in the bug report.
>Thanks for the virtualgl tip - it's possible that will be the fastest
>solution anyway, but I was really hoping to be able to try all the options
>and pick the best! I know there was a fuss a few years ago when IGLX was
>disabled by default, as some in the scientific community were using it --
>is that not still the case?
>Steve
> 
> References
> 
>Visible links
>1. mailto:i...@tzirechnoy.com

> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Indirect GLX still broken

[Ilya Anfimov]

On Tue, Jun 12, 2018 at 10:03:37AM +0100, Steve Dodd wrote:
>Hi all,
>Just wondering if there was any progress on:
>[1]https://bugs.freedesktop.org/show_bug.cgi?id=99555

 No, currently there is no developers willing to improve this.
 However, you can try some proxies like virtualgl.

>I have just hit this on Ubuntu 18.04. My use case is that I have a
>powerful but noisy "compute server" hidden in a closet and a low power
>fanless box basically acting as an old-fashioned X Terminal - but it does
>have a 3D-accelerated chipset and I would at least like to test/benchmark
>performance with indirect GLX (I have turned it on in xorg.conf)
>I am using the modesetting driver, but think I have also seen this on the
>old intel driver too (I can retest that if useful, but obviously
>modesetting is now everyone's focus.)
>Thanks,
>Steve
> 
> References
> 
>Visible links
>1. https://bugs.freedesktop.org/show_bug.cgi?id=99555

> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: XDestroyWindow can not really close the window

[Ilya Anfimov]

On Thu, May 10, 2018 at 06:23:08PM -0700, Alan Coopersmith wrote:
> On 05/10/18 06:17 PM, pengyixiang wrote:
> > Hello, everyone!
> >     I'm a newbie in xlib, I need to close the window while won't close the
> > program, [1] is my test code, here's the result in [2], XDestroyWindow 
> > passed,
> > but the window haven't close, Haven't I get the key to code it?
> 
> XDestroyWindow() just puts the request in the Xlib buffer but does not send
> it to the X server.

 I  think, it could be useful to note, that it does not necessary
send request to a server. It may. In  some  circumstances  or  on
some implementations. But it is not required to do so.

> 
> You need to put an XFlush() before the infinite sched_yield loop to cause it 
> to
> be sent to the server, or remove the infinite sched_yield loop to allow the
> program to loop back around to the XNextEvent() call which also flushes the
> Xlib request buffer.  (Though then you'll end up in an infinite error loop
> trying to destroy already destroyed windows.)
> 
> 
> -- 
>   -Alan Coopersmith-   alan.coopersm...@oracle.com
>Oracle Solaris Engineering - https://blogs.oracle.com/alanc
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Unsupported locale errors in XOrg

[Ilya Anfimov]

On Tue, Apr 10, 2018 at 02:17:13AM +0800, Prashanth Chandra wrote:
> Hello,
> 
> I'm getting "unsupported locale" warnings and crashes when running
> programs such as xterm or dmenu on a clean install of Ubuntu 17.10
> 
> Examples:
> warning: no locale support
> Warning: locale not supported by Xlib, locale set to C
> 
> Here's the offending line from dmenu's source code:
> 
> if (!setlocale(LC_CTYPE, "") || !XSupportsLocale())
> fputs("warning: no locale support\n", stderr);
> 
> I'm not 100% sure but I was told that this looks like an issue in XOrg.
> Additionally, the problem disappears if I change my default locale to
> en_US.UTF-8 instead of en_HK.UTF-8, which suggests that the issue is
> specific to my locale.
> 
> Here's the output of running locale:
> 
> LANG=en_HK.UTF-8
> LANGUAGE=en
> LC_CTYPE="en_HK.UTF-8"
> LC_NUMERIC="en_HK.UTF-8"
> LC_TIME="en_HK.UTF-8"
> LC_COLLATE="en_HK.UTF-8"
> LC_MONETARY="en_HK.UTF-8"
> LC_MESSAGES="en_HK.UTF-8"
> LC_PAPER="en_HK.UTF-8"
> LC_NAME="en_HK.UTF-8"
> LC_ADDRESS="en_HK.UTF-8"
> LC_TELEPHONE="en_HK.UTF-8"
> LC_MEASUREMENT="en_HK.UTF-8"
> LC_IDENTIFICATION="en_HK.UTF-8"
> LC_ALL=
> 
> Here's the output of running locale -a:
> 
> C
> C.UTF-8
> en_HK.utf8
> en_US.utf8
> POSIX
> 
> Would appreciate any pointers in understanding this issue.

 1) You could try to change environment to en_HK.utf8 
 The name is obviously different from en_HK.UTF-8, hoever,
this difference should give other diagnostic message.
 But you can try, it is simple.
 2) If not, check all places:
  /usr/share/X11/locale.dir 
   should contain a line
en_US.UTF-8/XLC_LOCALE: en_HK.UTF-8
  /usr/share/X11/locale.alias
   shouldn't contain a line beginning with en_HK.UTF-8:
  /etc/locale.gen 
  should have uncommented (i.e. without hash mark at the beginning) line
  en_HK.UTF-8 UTF-8
  and /etc/locale.alias shouldn't contain a line beginning with en_HK.UTF-8

> 
> Prashanth
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: How to convert ZPixMap to BGRA reliably?

[Ilya Anfimov]

On Fri, Aug 25, 2017 at 06:25:41PM +0530, Sai Prasanna wrote:
>I want to get the same values as got by using XGetImage for red_mask,
>blue_mask and green_mask in xcb.
>Here is m C-go lang code.
>I am iterating on the screen got from xcb_setup_roots_iterator .
>for depthIter := C.xcb_screen_allowed_depths_iterator(cx.screen);
>depthIter.rem != 0; C.xcb_depth_next(&depthIter) {
>d := depthIter.data
>for visual_iter := C.xcb_depth_visuals_iterator(d);
>visual_iter.rem != 0; C.xcb_visualtype_next(&visual_iter) {
>v := visual_iter.data
>fmt.Printf("MASKS %x, %x, %x", v.red_mask, v.green_mask,
>v.blue_mask)
>}
>}
> 
>Which Depth and Visual Id should I select for getting correct masks ?

 Generally,  VisualID  is inherited from a window you taking con-
tents of.
 I mean, if you are casting get_image on a window -- than  it  is
VisualID  of  that window, and if you do get_image on a pixmap --
than that pixmap is somehow filled with some data,  probably  via
XCopyArea,  and you should use VisualID of the window you used to
fill that pixmap.
 Also, you can fill the pixmap with drawing  functions  like  im-
age_text  or  poly_line or put_image requests -- than contents of
it's available planes is determined by your colors in  GC  and/or
your image data.


 The  Depth  should be the same that you used in XCreateWindow or
XCreatePixmap.

>On Wed, Aug 23, 2017 at 6:47 PM, Ilya Anfimov <[1]i...@tzirechnoy.com>
>wrote:
> 
>  On Tue, Aug 22, 2017 at 11:39:26AM +0530, Sai Prasanna wrote:
>  >I thought Zpixmap mapped directly to BGRA. But my assumption didn't
>  turn
>  >out to be correct in some older X versions.
>  >
>  >I am using xcb_get_image and xcb_shm_get_image to grab screen
>  pixels. I
>  >used Zpixmap option for image format. In new-ish Xorg versions it
>  works
>  >perfectly.
>  >
>  >But in some machines with older Xorg (1.15 and below) , I get
>  discolored,
>  >overlapped data, and it is less than 4 * width * height bytes. If I
>  try to
>  >read with bytes per pixel as 4 , overflow occurs.
>  >
>  >Could  this be some environment issue , or is there any other
>  "proper" way
>  >to convert Zpixmap to bgra/rgb formats?
> 
>   1) The best source of knowledge about core X11 functionality
>  is the "X Window System Protocol" book, available e.g. here:
> 
>[2]https://www.x.org/docs/XProtocol/proto.pdf
> 
>   2) The general pixel storage of the Z pixmap format is described
>  there in section 8 (Connection Setup), "Server  information"  and
>  pixel contents -- in "Visual information".
> 
>   It  does not need to be 4 bytes per pixel, or even integer bytes
>  per pixel. Number of bits per pixel is specified in FORMAT: field
>  of  server  connection  setup  response  (and  may  be  taken via
>  xcb_get_setup in xcb library).
>   Many X servers round pixel size up to integer number  of  bytes,
>  as  it  allows  some shortcuts and speedups in server implementa-
>  tion, but not all do that.
> 
>   Pixels does not need to be in {pad,r,g,b} format. The masks  for
>  red,  green and blue are specified in VISUALTYPE: field of server
>  connection setup response. Fortunately, that masks  are  contigu-
>  ous,  but  they  don't  need to lay on a byte boundary.  However,
>  modern processors don't care much about bit shift  size,  and  it
>  does not matter -- shift by 8 bits or 11.
> 
>   Also,  pixels  will  be in different byte orders as specified by
>  image-byte-order: field in server response. You should prepare to
>  access  individual  bytes, not integers (or find some other solu-
>  tion).
> 
>   It  would be good to build you program for something like Debian
>  mips architecture (not mips-el!) and check  all  combinations  of
>  your program and X server in something like qemu-system-mips.
> 
>   PS  And  yes,  probably  the most recommended ways to read image
>  from X11 is to use some image manipulation library,  like  libgdk
>  or imagemagick.
>   The  required  transformations are fairly simple, though, and if
>  you are messing with xcb, that it  should  be  really  simple  to
>  write a conversion code in like 30-50 lines.
> 
>  ___
>  [3]xorg@lists.x.org: X.Org support
>  Archives: [4]http://lists.freedesktop.org/ar

Re: How to convert ZPixMap to BGRA reliably?

[Ilya Anfimov]

On Tue, Aug 22, 2017 at 11:39:26AM +0530, Sai Prasanna wrote:
>I thought Zpixmap mapped directly to BGRA. But my assumption didn't turn
>out to be correct in some older X versions.
> 
>I am using xcb_get_image and xcb_shm_get_image to grab screen pixels. I
>used Zpixmap option for image format. In new-ish Xorg versions it works
>perfectly.
> 
>But in some machines with older Xorg (1.15 and below) , I get discolored,
>overlapped data, and it is less than 4 * width * height bytes. If I try to
>read with bytes per pixel as 4 , overflow occurs.
> 
>Could  this be some environment issue , or is there any other "proper" way
>to convert Zpixmap to bgra/rgb formats?

 1) The best source of knowledge about core X11 functionality
is the "X Window System Protocol" book, available e.g. here:
  
  https://www.x.org/docs/XProtocol/proto.pdf

 2) The general pixel storage of the Z pixmap format is described
there in section 8 (Connection Setup), "Server  information"  and
pixel contents -- in "Visual information".

 It  does not need to be 4 bytes per pixel, or even integer bytes
per pixel. Number of bits per pixel is specified in FORMAT: field
of  server  connection  setup  response  (and  may  be  taken via
xcb_get_setup in xcb library).
 Many X servers round pixel size up to integer number  of  bytes,
as  it  allows  some shortcuts and speedups in server implementa-
tion, but not all do that.

 Pixels does not need to be in {pad,r,g,b} format. The masks  for
red,  green and blue are specified in VISUALTYPE: field of server
connection setup response. Fortunately, that masks  are  contigu-
ous,  but  they  don't  need to lay on a byte boundary.  However,
modern processors don't care much about bit shift  size,  and  it
does not matter -- shift by 8 bits or 11.


 Also,  pixels  will  be in different byte orders as specified by
image-byte-order: field in server response. You should prepare to
access  individual  bytes, not integers (or find some other solu-
tion).

 It  would be good to build you program for something like Debian
mips architecture (not mips-el!) and check  all  combinations  of
your program and X server in something like qemu-system-mips.


 PS  And  yes,  probably  the most recommended ways to read image
from X11 is to use some image manipulation library,  like  libgdk
or imagemagick.
 The  required  transformations are fairly simple, though, and if
you are messing with xcb, that it  should  be  really  simple  to
write a conversion code in like 30-50 lines.




___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: 4K SMPTE Standard Outputs

[Ilya Anfimov]

On Tue, Jul 04, 2017 at 03:54:46PM -0400, Trevor Childs wrote:
>   I meant -- what hardware generates that signal?
> 
>The Linux system is an Nvidia Jetson TX1 developer kit, running Ubuntu
>16.04. The output is done over the board's HDMI (2.1, type A) port, either
>direct into the recorder or through an AJA HA5-4K HDMI to SDI converter.

 Well, documentation said that the most default pixel clock
source for HDMI is PLL_D2, and it have precision clock stepping:
 either 38.4 MHz / DIVM * DIVN / DIVP (SDM disabled)
 or
  38.4 MHz / DIVM * (DIVN + 0.5 + SDM_DIN/8192) / DIVP
  (SDM enabled) DIVM, DIVN 8-bit, SDM_DIN 16 bit.
  I miss the point whether it is further divided by 2

  Anyway, something like SDM, M=1, N=14, SDM_DIN=7936
  (or M=1, N=28, SDM_DIN=19968) should get exactly 940 MHz pixel clock.

  So, rounding to picoseconds looks like error in NVidia kernel code,
please fix it yourself or ask them to fix it.


___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: 4K SMPTE Standard Outputs

[Ilya Anfimov]

On Tue, Jul 04, 2017 at 01:42:16PM -0400, Trevor Childs wrote:
>   And what is the hardware you are trying to setup?
> 
> The recorder is an Atomos Shogun Inferno. It has HDMI 2.1 as well as quad
>SDI inputs.
 
 I meant -- what hardware generates that signal?

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: 4K SMPTE Standard Outputs

[Ilya Anfimov]

On Tue, Jul 04, 2017 at 11:00:51AM -0400, Trevor Childs wrote:
>I've run into a problem setting display modes. I'm attempting to output
>3840x2160 @ 60Hz to a hardware recorder but the standard modes for 60Hz
>and 59.94Hz actually come out to 60.02Hz and 59.98Hz. EDID data has
>1080p@60 as it's preferred mode, and scaling the numbers up leads to the
>same rounding error (60.02Hz) as the predefined modes have.
>Here's the modeline that has the incorrect refresh rate:
>"3840x2160"   594.18   3840 4016 4104 4400   2160 2168 2178 2250
>Here's how it's defined in kernel_source/drivers/video/modedb.c:

 And what is the hardware you are trying to setup?
 How pixel clock is defined there? With ~300 kHz steps?
 What modelines got you 60.02 and 59.98 Hz?
 Btw, if they are really close to 60.02 and 59.98, than one step down
should be around 59.94.


>{.refresh = 60, .xres = 3840, .yres = 2160, .pixclock = 1683,
>.left_margin = 296, .right_margin = 176,
>.upper_margin = 72, .lower_margin = 8,
>.hsync_len = 88, .vsync_len = 10,
>.sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
>.flag = FB_FLAG_RATIO_16_9,
>.vmode = FB_VMODE_NONINTERLACED},
>The recorders are expecting SMPTE standard inputs, and reject the current
>ones. I can use either 3840x2160 or 4096x2160, and the refresh rate can be
>either 60Hz or 59.94Hz.
>I have tested the other modes available, and 1080p works fine at 60Hz.
>Both 4K modes work at 30Hz. It's when trying to set 4K @ 60Hz that the
>granularity of the pixclock ends up being a problem (it would need to be
>1683.5 for the math to work out the same as the other modes).
>I attempted using cvt, cvt12, and gtf to generate modelines, but none of
>them work either. I also used the source code from those programs to
>attempt a brute-force method by generating as many modelines as I could
>that end up within 0.0001% of the correct refresh rates (same accuracy as
>the EDID's 1080p@60 mode, which is actually 60.6Hz). That generated
>1520 possibilities that followed the math rules for modelines, but none of

 This suggests that it could be not the uneven refresh rate problem.
 It would be a bit strange to create recorder that can synchronize to 60 and 
59.94,
but cannot on other +-0.5% errors.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: SDL2 based X servers

[Ilya Anfimov]

On Sat, Apr 29, 2017 at 10:19:10PM +0200, S??awomir Lach wrote:
> Hi.
> 
> Anybody knows any complete X server using SDL2 library. If not, is

Yes: 
https://github.com/pelya/commandergenius/tree/sdl_android/project/jni/application/xserver

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: XLib and Xvfb: capture screen

[Ilya Anfimov]

On Wed, Feb 08, 2017 at 01:16:18PM +0300, Alex Sviridov wrote:
>Hi all
> 
>This is my c++ code which I use to capture screen:
>Display* display = XOpenDisplay(NULL);
>Window root = DefaultRootWindow(display);
>XWindowAttributes attributes = {0};
>XGetWindowAttributes(display, root, &attributes);
>int width, height;
>width = attributes.width;
>height = attributes.height;
>XImage* img = XGetImage(display, root, 0, 0 , width, height,
>AllPlanes, ZPixmap);
>...
>XDestroyImage(img);
>XCloseDisplay(display);
> 
>When I run it without Xvfb I get a normal screen picture. However, when I
>use it in Xvfb is not not normal. For example I tried to capture youtube
>in firefox as a result I see some green/blue image with you tube pieces.
> 
>This question was asked on stackoverflow
>[1]http://stackoverflow.com/questions/42110050/xlib-and-xvfb-capture-screen
>and there can be seen the result image.
> 
>How to fix it?

 Try
Section "Extensions"
  Option"XVideo""Disable"
EndSection

in xorg.conf, or -extensionXVideo in Xvfb command line.


___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Xlib: capture screen in separate xserver session

[Ilya Anfimov]

On Tue, Feb 07, 2017 at 09:47:43PM +0300, Alex Sviridov wrote:
>Hi all.
> 
>I need to run some-program which makes screen capturing via xlib library
>in separate xserver session. So, I start my ubuntu 14 and `origin` xserver
>session (lets call it this way) starts. After that I run
> 
>startx some-program

[skipped]

>xserver session while it is not active (the user is using another
>xsession).

  Using  it  this  way  is nearly impossible: for some historical
reasons, inactive server stops drawing. Well, not  just  histori-
cal:  it  is  a  reasinable approach to stop wasting resources to
draw unseen things.

 However, you can start virtual X server  (like  standard  Xvfb),
and draw on it just fine.
 You  can  even  try  to work interactively with programs on that
server via something like x2x or  x11vnc  or  x2godesktopsharing,
however,  usually  interactive experience is worse than with con-
sole server.
 Also, no hardware 3D acceleration will  be  available.  It  also
works  only  on active console currently. If you need it, you can
try to use some server-in-window servers like xpra,  however,  it
is  not  perfect (and all attempts to implement it in the past --
Xgl, AIGLX was not perfect also).

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Trying to use an xlib GXxor

[Ilya Anfimov]

On Mon, Feb 06, 2017 at 09:45:20AM -0500, Alan Corey wrote:
> >
> >  To get the "blackcolor" over "whitecolor" with GXxor, you should
> > draw with "blackcolor^whitecolor".
> >  (because the result would  be
> > "whitecolor^(blackcolor^whitecolor)".
> >
> >  In fact, on most displays blackcolor is an integer with the val-
> > ue 0, therefore xor with just blackcolor does nothing.
> >
> 
> Sure enough, blackcolor is 0, thanks.  I did XSetForeground to
> whitecolor and it works fine.  Now I can press onward and wow the

 Setting  foreground in xor to whitecolor is exactly the same er-
ror as setting it to blackcolor, just the bug could  be  seen  in
other, less common server setups.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Trying to use an xlib GXxor

[Ilya Anfimov]

On Sun, Feb 05, 2017 at 08:18:41PM -0500, Alan Corey wrote:
> This probably isn't exactly the right list for this, but maybe
> somebody lingering can answer.  I'm trying to use xor to put a line on
> the screen then erase it again when I want.  With the XSetFunction()
> to xor uncommented I get no line.  If I comment it out I get a line,
> but no erase.  If I move it between the draws I get no erase.
> 
> xor (exclusive or) should set every bit where there's one and only one
> of the inputs true.  If you xor something to the screen twice the 2nd
> time erases what you wrote the first time.  Except I'm doing something
> wrong or there's something I didn't consider.

 To get the "blackcolor" over "whitecolor" with GXxor, you should
draw with "blackcolor^whitecolor".
 (because the result would  be
"whitecolor^(blackcolor^whitecolor)".

 In fact, on most displays blackcolor is an integer with the val-
ue 0, therefore xor with just blackcolor does nothing.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Need help understanding X server freeze

[Ilya Anfimov]

On Mon, Oct 03, 2016 at 11:22:36PM +0530, jeetu.gol...@gmail.com wrote:
> Hi everyone,
> 
> First, I am a big fan of the remote display capabilities of X, thank
> you very much to all who have worked on this project over the years.
> 

 You  could  try to use wireshark and/or tcpdump to dump and ana-
lyze what's going on on the connection on the ssh  server   side.
In  fact, DISPLAY localhost:10.0 points toad-
dress/port 127.0.0.1:6010 , which could be easily captured.

 Also, the Debian distribution  contains  debugging  symbols  for
xorg  X  server and most of it's drivers. Analyzing the internals
of X server with gdb is really easy when using them.

 Just beware, that gdb stops process it attach to -- therefore it
is  not  reasonably  to do that from client of that X server (or,
sometimes it is, when all is done by some script, but you  should
have a reasonable way to quit gdb).

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Bug (?) in compose

[Ilya Anfimov]

On Mon, Oct 03, 2016 at 10:48:33AM +0300, Clock Source wrote:
> On Sat, 1 Oct 2016 11:46:59 +0300
> Ilya Anfimov  wrote:
> 
> >  Motif  and  xforms  shows  german  ss ligature, but emits single
> > (last entered) f instead of ff ligature and single (last entered)
> > o instead of promille ligature.
> 
> Incredible. Sounds like a bug...

 Definitely  yes,  and  GTK situation definitely is the bug also.
But, fortunately, all of that is not x.org projects.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Bug (?) in compose

[Ilya Anfimov]

On Fri, Sep 30, 2016 at 08:33:53AM -0700, Alan Coopersmith wrote:
> On 09/30/16 08:32 AM, Clock Source wrote:
> >On Fri, 30 Sep 2016 18:24:15 +0300
> >Ilya Anfimov  wrote:
> >
> >
> >> And how do you try to print that characters?
> >>
> >> (I could also note, that xev output is exactly that
> >>is expected when typing that composed sequences)
> >
> >I print Compose + symbols in X-applications, such as
> >leafpad/browser/mail client/libreoffice etc...
> >
> >...and copypaste with "missing" symbols works perfectly even in
> >cleartext applications (leafpad and similar)
> 
> Note that some toolkits such as GTK use their own input handling and
> their own Compose key tables, not the Xlib ones.

 Confirming: all gtk2 apps silently skips ff ligature.

 Xaw, tcl/tk, Qt, gtk3 are fine.
 Strange  situtation with libreoffice: apparently the same libre-
office 4.3.3.2, Build ID 430m0(Build:  2),  from  debian  Jessie,
packageInstalled:  1:4.3.3-2+deb8u5,  works from one computer
and skips ff from the other, on the same X server.
 links browser skips ff, but it apparently does not  have  it  in
it's font (answer from Xutf8LookupString is fine).

 Promille is fine in all of the above, including gtk2 apps.

 Motif  and  xforms  shows  german  ss ligature, but emits single
(last entered) f instead of ff ligature and single (last entered)
o instead of promille ligature.


___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Bug (?) in compose

[Ilya Anfimov]

On Fri, Sep 30, 2016 at 05:58:56PM +0300, Clock Source wrote:
> 
> 
> On Fri, 30 Sep 2016 17:18:31 +0300
> Ilya Anfimov  wrote:
> 
> > On Fri, Sep 30, 2016 at 04:25:20PM +0300, Clock Source wrote:
> > > Good day!
> > > 
> > > Please get me a tips, where I must catch bug. Not all compose
> > > combinations work. For example:  
> > 
> >  Why do you think that something does not work?
> 
> In case "not work", no character printed at all. 

 And how do you try to print that characters?

 (I could also note, that xev output is exactly that
is expected when typing that composed sequences)
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Bug (?) in compose

[Ilya Anfimov]

On Fri, Sep 30, 2016 at 04:25:20PM +0300, Clock Source wrote:
> Good day!
> 
> Please get me a tips, where I must catch bug. Not all compose
> combinations work. For example:

 Why do you think that something does not work?

> 
>: "??"   ssharp # LATIN SMALL LETTER 
> SHARP S
>  - work, xev output:
> KeyPress event, serial 39, synthetic NO, window 0x501,
> root 0x262, subw 0x0, time 2509703, (375,120), root:(385,201),
> state 0x0, keycode 0 (keysym 0xdf, ssharp), same_screen YES,
> XLookupString gives 0 bytes: 
> XmbLookupString gives 2 bytes: (c3 9f) "??"
> XFilterEvent returns: False
> 
> 
> 
>: "???"   Ufb00 # LATIN SMALL 
> LIGATURE FF
>  - not work, xev output:
> KeyPress event, serial 39, synthetic NO, window 0x501,
> root 0x262, subw 0x0, time 2593224, (321,71), root:(331,152),
> state 0x0, keycode 0 (keysym 0x100fb00, UFB00), same_screen YES,
> XLookupString gives 0 bytes: 
> XmbLookupString gives 3 bytes: (ef ac 80) "???"
> XFilterEvent returns: False
> 
> 
> and that work too:
>  : "???"   U2030 # PER MILLE SIGN
> 
> KeyPress event, serial 39, synthetic NO, window 0x501,
> root 0x262, subw 0x0, time 2799406, (319,50), root:(329,131),
> state 0x0, keycode 0 (keysym 0x1002030, U2030), same_screen YES,
> XLookupString gives 0 bytes: 
> XmbLookupString gives 3 bytes: (e2 80 b0) "???"
> XFilterEvent returns: False
> 
> 
> How I may solve this puzzle?
> 
> -- 
>   Best regards, V.
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Open Shared Memory and Render Pictures

[Ilya Anfimov]

On Fri, Aug 05, 2016 at 02:53:06PM +0200, Michael Titke wrote:

[skipped]

> 
> I'm just asking because solving a puzzle is funny but maybe someone still
> knows about those "private" protocol "mechanics".

 All of that protocol mechanics is described in the X Window Sys-
tem Protocol X Consortium Standard.
 Any your misunderstanding means that you misread  some  part  of
that book.
 There  is  no other possibilities with the CORE at your level of
confidence with the protocol.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Indirect OpenGL -- partially working?

[Ilya Anfimov]

On Wed, Jun 15, 2016 at 05:05:28PM -0700, L. A. Walsh wrote:
> 
> 
> 
> 
> Thomas L??bking wrote:
> >On Tue, May 31, 2016 at 08:33:14AM -0700, L. A. Walsh wrote:
> >>Glynn Clements wrote:
> >>>L. A. Walsh wrote:
> >>>
> I have sometimes gotten some GLX programs to work for a short while,
> but more often than not, I don't get them to work at all.
> >>>
> >>>The most likely reason for this is that the program needs a later
> >>>version of OpenGL than Cygwin's X server provides.
> >>
> >>  Hmmmwhat does this mean, then?
> >>OpenGL vendor string: NVIDIA Corporation
> >>OpenGL renderer string: GeForce GTX 590/PCIe/SSE2
> >>OpenGL version string: 1.4 (4.5.0 NVIDIA 355.98)
> >
> >Indirect GL is confined to GL 1.4 (ie. fixed function path, notably no
> >glsl)
> >The driver and GPU support 4.5, but only on direct contexts.
> >
> >You should check whether indirect GL works generally (there're somet
> >pitfalls), ie. whether glxgears works.
> >If so, you best contact the authors of the failing GL clients and ask
> >whether they provide a fixed function path (and how to select it)
> 
> Glx gears draws the gears but they don't move.

 Yes, interesting set of bugs.
 Drawing requests from glxgears are small, and X11 holds a lot of
them in it's receive buffers. Sometime ago I had ~16k requests on
nvidia card with nvidia driver.
 As  the  new glxgears calculates per-frame rotation from fps, it
receives very large fps value (16k requests gets out  almost  in-
stantly)  and  sets  very  low per-frame rotation. On the screen,
however, there is usually 60 fps rendering speed -- as it is sync
to vblank.
 This results in the very slow visible gear motion.

 Also,  after  pulling  16k requests, glx would stack and prevent
glxgears from pulling more. This would  result  in  glxgears  not
printing it's fps results for some time.

 And even suspended glxgears would draw something for minutes.

 Well,  XFlush()  after  frame drawing in glxgears would fix that
more or less fine.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Novice trying to understand Xrandr and multi monitor setup

[Ilya Anfimov]

On Tue, May 24, 2016 at 08:38:53PM -0700, TJ Olaes wrote:
>Good evening.
>I have a dual monitor setup and am trying to figure out why ScreenCount
>returns 1.  My code is as follows:

 Good day.

 The ScreenCount is not a RANDR call.
 This  is  from CORE multihead support attempt. That model have a
large pile of drawbacks now: it is very hard to move window  from
one  monitor  to another, or to dynamically make second monitor a
copy of first one, or join monitors in other sensible  configura-
tion.  In  fact,  distinct  screens was almost isolated from each
other.
 Therefore, in attempt to have a good support of  multihead,  new
extensions  introduced,  that  lists all monitors in one CORE X11
screen, and manipulates them by itsel: first was  Xinerama,  than
(and now) RANDR.
 The CORE multiple screens is almost unsed now (well, AFAIK
fglrx creates two screens on dual-GPU notebooks: one with slow
in-CPU accelerator, and one with discrete GPU).

 So  you  should  read  RANDR spec to get information about yoour
monitors.

[skipped]

>FWIW I'm using Xrandr, and I've tried doing "xrandr --auto" just to see
>what it detects and I still get the same result.  I'm completely lost

 It is very strange that you see some result of xrandr --auto.
 Usually,  it is completely silent. xrandr -q  is for getting in-
formation.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Incorrect XFontStruct entries in an XFontSet

[Ilya Anfimov]

On Fri, May 20, 2016 at 09:33:01PM +0300, Andrey ``Bass'' Shcheglov wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hello,
> 
> I've encountered a problem of XFontSet "expansion" in libX11.
> 
> Consider the following C code:
> 
> 
> In ru_RU.ISO-8859-5 locale,

[skipped]

> The practical effect of this behaviour is that Motif, for instance,
> refuses to draw a string at all (see this SO question for screenshots:
> ).
> 
> 
> I've run a research and found out different libX11 versions from
> different vendors exhibit different behaviour in ru_RU locale (in

 Well,  ru_RU  locale  in X11 is expanded to X11 locale rules ac-
cording to /usr/share/X11/locale/locale.alias
 (or /usr/X11R6/lib/locale/locale.alias,  or  something  similar,
determined  by  compile-time  and usually according to local unix
version rules).

 The X11 default was ru_RU.KOI8-R for a long time, and  somewhere
in  mid-2000 it changed to ru_RU.UTF-8. However, a packager defi-
nitely should change it to system value of ru_RU  locale  (proba-
bly, ru_RU.ISO8859-5 on Solaris).

 If  the  X11  ru_RU  points  to  ru_RU.UTF-8,  and system one is
ru_RU.ISO8859-5, then your example should not display  something,
really,  as  a  russian  text  in  ISO8859-5 is not a valid UTF-8
string, apart from spaces and puntuation.
 And this is not an error of font  list expandsion itself, it  is
encoding error.

 However I had found found  that in stable Debian the ru_RU.UTF-8
in  this example does not work either (both by full name and when
written by some alias). It looks like it just cuts off 8th bit of
text, displaying apostrophe and some other ascii letter for every
russian letter.

en_US.UTF-8 surprisingly does works, and when
   /usr/share/X11/locale/en_US.UTF-8/XLC_LOCALE
 is copied to  /usr/share/X11/locale/ru_RU.UTF-8/XLC_LOCALE,  the
ru_RU.UTF-8 starts working as needed.
 The file itself looks generally OK.
 Xaw  widgets  and  Xlib  XmbDrawText works just fine, so this is
probably some motif error. I am continuing investigation.

[skipped]

> Questions:
> 
> - - Is this a known issue?

 Probably not.

> - - How can I further diagnose it? Have taken a look at libX11 source
> code, but don't have a clue so far.
> - - Where should I report a bug? Particularly, which bugzilla project
> and component correspond to libX11?

 at least ru_RU alias should be reported to you package maintainer.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X/Render, rotation transform, Src PICTOP: can I ignore pixels in the bounding box but outside the polygon?

[Ilya Anfimov]

On Sun, May 22, 2016 at 03:07:17PM +1000, Nigel Tao wrote:
> On Wed, May 18, 2016 at 8:07 PM, Ilya Anfimov  wrote:
> >  But  anyway  you can specify clip-mask with ChangePicture to use
> > bitmap of enabled pixels. Whould be better IMO  than  restricting
> > output line-by-line.
> >  And that mask bitmap also could be calculated by RENDER.
> 
> I suppose that will 'work', clipping the dst rather than the src,
> although it seems inefficient to allocate and clean up an entire
> Pixmap for the mask every time I want to do this...

 Well, it's inefficiency needs investigation.

 And inefficiency of alpha operation needs investigation too.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X/Render, rotation transform, Src PICTOP: can I ignore pixels in the bounding box but outside the polygon?

[Ilya Anfimov]

On Wed, May 18, 2016 at 10:06:03AM +1000, Nigel Tao wrote:
> I sent this a few months ago, but got no response, not even a "what
> you're asking for isn't possible". I'd still like to know the answer
> (even if it's no), so I'm sending it out another (final) time.

 Well,  don't  know about RENDER capabilities (I always miss what
is in the spec, what is wanted by the designer and what is really
implemented with this extension).

 But  anyway  you can specify clip-mask with ChangePicture to use
bitmap of enabled pixels. Whould be better IMO  than  restricting
output line-by-line.
 And that mask bitmap also could be calculated by RENDER.

> 
> 
> On Sat, Oct 10, 2015 at 3:38 PM, Nigel Tao  wrote:
> > I'm using X Render, and want to draw a playing card image onto my
> > window, rotated (e.g. as part of a fan of cards in hand).
> >
> > For simplicity, suppose that playing cards are square and the rotation
> > is by 45 degrees. The result is a diamond shape, so that in its
> > bounding box, the pixels in (1) and out of (0) that diamond looks
> > like:
> >
> > 00100
> > 01110
> > 1
> > 01110
> > 00100
> >
> > Labeling the interesting points on the edges of that bounding box as:
> >
> > ABC
> > HXD
> > GFE
> >
> > with the center point as X, that means that the bounding box is ACEG
> > and the playing card is BDFH.
> >
> > For a fully opaque source image, the result is the same inside the
> > diamond BDFH, for the Src and Over Render PICTOPs.
> >
> > I am also guessing that, in general, the Src operator is faster than
> > Over, since it does not have to read and blend the destination pixels
> > at all. Thus, I'd like to use the Src operator if possible.
> >
> > The thing is, outside the diamond, in the '0' pixels above, the
> > resultant pixels are black with Src, and unchanged, obviously, with
> > Over.
> >
> > In contrast, in OpenGL say, if my (transformed) vertices are BDFH,
> > then the pixel shader only touches the '1' pixels and leaves the '0'
> > pixels alone, regardless of whether I use the equivalent of Src or
> > Over in my pixel shader.
> >
> > Is there a way I can use the Src operator, in Render, and touch only
> > the '1' pixels? I've tried a mixture of the Composite and TriStrip
> > requests, with SetPictureTransform, and setting a clip (but
> > SetPictureClipRectangles takes a union of axis-aligned rects, AFAICT),
> > but I haven't been able to make it do what I want. Am I missing
> > something obvious?
> >
> > Sure, technically, I could calculate the diamond client-side, and send
> > a series of one-pixel-high strips to the server, but that feels
> > inelegant at best.
> >
> > For this particular card-playing app, an easy, practical solution is
> > to just use the Over operator instead of Src. I'm not really writing a
> > card-playing app, though. I'm writing a graphics library, for which
> > there'll be both OpenGL-based and X11/Render-based backends, and I'd
> > like 'draw this texture with this affine transform and this
> > Porter-Duff operator' to work the same on both backends.
> >
> > I had a quick skim through the cairo xlib render source code, but
> > nothing leapt out as specifically looking at this case.
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: error when execute the Xorg(XKB: Failed to compile keymap)

[Ilya Anfimov]

On Tue, May 10, 2016 at 05:09:52PM +0800, ?? wrote:

[skipped]

> at http://wiki.x.org
> for help.
>(EE) Please also check the log file at "/usr/local/var/log/Xorg.1.log"

 And what is in /usr/local/var/log/Xorg.1.log ?

PS Probably, there is missing files somewhere around /usr/local/share/X11/xkb ,
but logs should tell it exactly.

>for additional information.
>(EE)
>(EE) Server terminated with error (1). Closing log file.
>can you tell me what should I do? thank you.


> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: How could an application know the desktop scale factor? ????

[Ilya Anfimov]

On Fri, May 06, 2016 at 04:54:10PM +0200, Alberto Salvia Novella wrote:
> Is there any way an application could tell the current desktop scaling
> factor independently of the desktop environment in use?
> 
> For example Wayland has
> (https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_output)
> and Mir has (https://unity.ubuntu.com/mir/struct_mir_display_output.html),
> which both could be used for telling the physical size of the output device.

 Obtaining  physical  size is relatively easy: if RANDR extension
is supported, than try to get information  with  XRRGetScreenInfo
on  your  window, and get per-axis dpi by dividing current screen
size in mm by current screen size in pixels, multiplied  by  25.4
(with respect to current rotation, as sizes reported for original
x/y axes, and their meaning could be changed by rotation).

With RANDR you can also subscribe  to  screen  resolution  change
events.

 If RANDR is not supported or reports 0 screen size -- than fall-
back to using XDisplayHeightMM/XDisplayHeight and  XDisplayWidth-
MM/XDisplayWidth.

 It looks like there is no practice of regular scaling windows by
a compositing WM, so you can assume that scaling factor is 1.


> So you can tell how to scale your application interface to have a good size.
> 
> This is for solving bug (https://developer.blender.org/T48292).
> 
> Thanks in advance.
> 
> 



> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Strange results from xdpyinfo

[Ilya Anfimov]

On Sat, Apr 23, 2016 at 06:28:55PM +0100, David C. Partridge wrote:
>When using two relatively recent X implementations (VcxSrv, Ubuntu
>14.04) an X client reports strange results from xdypinfo.
> 
> 
>Specifically there are multiple (many, many) results looking like:

 It's  not strange. It should be expected now. In fact, it is GLX
that require special visual for any  sane  combination  of  basic
properties like Z-buffer, stencil, double buffer and some others.

 Nevertheless,  this  behaviour is perfectly adheres to spec, and
is here for a long time and doesn't cause much trouble.

[skipped]


>this is blowing the buffer for an application that uses xdpyinfo to
>determine the display resolution to use.

 Such a pity.

> 
> 
>By contrast OpenText Exceed shows only ONE 24 plane entry.
> 
> 
>Is there any fix for this problem?

 There is no problem and no need to fix.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Clock Widget Resources?

[Ilya Anfimov]

On Wed, Mar 02, 2016 at 06:45:49AM +, David Woodfall wrote:
> Hi,
> 
> According to the xclock manpage:
> 
> "This program uses the Clock widget.  It understands all of the core
> resource names and classes as well as: ..."
> 
> Where can I find a full list of the clock widget resources?

 Common resources are described in "Athen Widget Set - C Language Interface"
section 2.4 "Common Resources".

  The book is bundled with X11, or at least it was some time ago,
and could be easily found by googling.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Diagnosing first vs subsequent performance

[Ilya Anfimov]

On Tue, Jan 19, 2016 at 12:54:15PM -0700, Lloyd Brown wrote:
> Sure.  I've generated them using something like this:
> 
> > $ for i in {0..3}; do echo "Testing display $i"; for j in {1..2}; do
> > echo "Instance $j"; DISPLAY=:${i}.0 glxinfo >
> > /tmp/glxinfo.display${i}.instance${j}; echo "sleeping 30s"; sleep 30;
> > echo "---"; done; echo "sleeping 5s"; sleep 5; echo "--"; done
> 
> Note that I did add the delays on purpose.  For some reason, when I ran
> the loop without them, it would hang up the second Xorg display
> (DISPLAY=:1.0, in this case), when it got to the second glxinfo.  I
> don't entirely know what was going on, but the delays seemed to help it
> complete.
> 
> I admit that I'm curious to know what you're looking for in the attached
> documents, but if you're trying to verify that the first and second
> calls to glxinfo are the same, they certainly are.  Here are the MD5SUMs:

 I expected that, probably, server would
fail to initialize NV-GLX direct rendering extension and this would
result in indirect glx rendering.
 
 My expectations was wrong. Probably.

> 
> > $ md5sum glxinfo.display*
> > 97379d9a7c3332e660ec71a045d6ea1f  glxinfo.display0.instance1
> > 97379d9a7c3332e660ec71a045d6ea1f  glxinfo.display0.instance2
> > d6484c73ca120a43f4b1abc5b508c168  glxinfo.display1.instance1
> > d6484c73ca120a43f4b1abc5b508c168  glxinfo.display1.instance2
> > ba989769089853b4cd44bb6c68a53a80  glxinfo.display2.instance1
> > ba989769089853b4cd44bb6c68a53a80  glxinfo.display2.instance2
> > 11be7dc4379f37cbeeef346df799014b  glxinfo.display3.instance1
> > 11be7dc4379f37cbeeef346df799014b  glxinfo.display3.instance2
> 
> Note that I did upgrade to the RHEL xorg-x11-server-Xorg RPM to
> v1.15.0-36.  It did not have any effect; the same behavior occurred
> either way.
> 
> 
> Lloyd
> 
> 
> On 01/19/2016 12:05 PM, Ilya Anfimov wrote:
> > Good day. Could you provide glxinfo output, first and second run on
> > different displays?
> 
> -- 
> Lloyd Brown
> Systems Administrator
> Fulton Supercomputing Lab
> Brigham Young University
> http://marylou.byu.edu
> 


> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Diagnosing first vs subsequent performance

[Ilya Anfimov]

On Tue, Jan 19, 2016 at 11:54:43AM -0700, Lloyd Brown wrote:
> I will try, but honestly, I'm not certain if it will instantiate the
> server or not. 
> 
> I was mostly following the recommendations from the "Setting up the X
> Server for Headless Operation" (pg 15) of this document:
> http://www.nvidia.com/content/PDF/remote-viz-tesla-gpus.pdf
> 
> 
> 
> On 01/19/2016 11:19 AM, Christopher Barry wrote:
> > This may or may not be useful, so sorry if I'm speaking out of turn,
> > but is it not possible to supply only the snippet of config that is
> > unique (e.g. the Device section), and allow X to do the rest? If it is,
> > this might be a way to remove other config data that could be part of
> > the issue. Again, just guessing, and might be a quick and easy test.
> 

 Good day.

 Could you provide glxinfo output, first and second run
on different displays?

> -- 
> Lloyd Brown
> Systems Administrator
> Fulton Supercomputing Lab
> Brigham Young University
> http://marylou.byu.edu
> 
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: setxkbmap search path

[Ilya Anfimov]

On Sun, Dec 13, 2015 at 04:20:52PM +0100, EatsKittens wrote:

Good day!

>By default, `setxkbmap` searches for. files within
>`/usr/share/X11/xkb`. Is there any way to make it in order search into
>`{$HOME/.local,/usr/local,/usr}/shareX11/xkb`.
>My current setxkbmap inside my `~/.xinitrc` looks like this:
>setxkbmap -compat custom -keycodes custom custom shift
>I would like to be able to use something like this without having to
>pollute the `/usr/share` namespace with custom files like
>`/usr/share/X11/xkb/{compat,keycodes,symbols}/custom`
>Using `-I ~/.local/share/X11/xkb` which I tried to add in front of it
>does not seem to work even with a fully copied directory structure.

 You could use

 setxkbmap -compat custom -keycodes custom custom shift -print|xkbcomp -I 
~/.xkb/ - "$DISPLAY"


> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X Core Protocol Scheme

[Ilya Anfimov]

On Sun, Dec 13, 2015 at 10:19:59AM +0100, Michael Titke wrote:

Good day!

[skipped]

> When we add the keymap events to the event mask of the window (bit-or
> cw-keyboard cw-keymap) (BTW it's nice the core specifications containts Lisp
> like hexidecimal numbers which allows for copy & paste: (define cw-keymap
> (number->byte-string-4 #x4000))) we only receive void keymap events but
> they really do appear for every suppressed enter notification:
> 
> VSI SCA/X: unhandled event: #"11 0 0 0  16 0 0 0  0 0 0 0  0 0 0 0 0 0 0 0
> 0 0 0 0  0 0 0 0  0 0 0 0"
> VSI SCA/X: unhandled event: #"11 0 0 0  0 0 0 0  0 0 0 0  0 0 0 0  0 0 0 0
> 0 0 0 0  0 0 0 0  0 0 0 0"

 This  is exactly the behaviour specified in the X11 protocol de-
scription.
 Look at KeymapNotify event description (which  you  request  via
#x4000 event mask).

 btw,  it  is  not  void  events: first one, in current linux PC,
should indicate that the Return key is pressed.

 And it is not related to keymaps. There is  MappingNotify  event
for keymaps, and you cannot request it as it is always reported.
 (And it is relatively rare event for most  setups,  and  may  be
even  never will come to your app, however this does not mean you
can ignore it)

> 
> 
> No matter what the request to receive the current mappings
> (X-get-keyboard-mapping X) is silently ignored.

 Most  probably  you  have  another off-by-one error or something
wrong with error dispatcher or so.
 But give me tcpdump -w of complete session, then there  will  be
some base about your statements.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X Core Protocol Scheme

[Ilya Anfimov]

On Sat, Dec 12, 2015 at 06:31:55PM +0100, Michael Titke wrote:
> 

[skipped]

> >  This is described in Expose event paragraph in section 11 of the
> >protocol specification.
> >
> >btw, this automatically means  that  you  should  receive  Expose
> >events  on  the  window you want to draw and therefore select Ex-
> >posure in the event mask at a window creation.
> 
> Listening for expose events sounds like a good idea but the relation between
> graphics operation, their effect and expose events doesn't seem to be stated
> in the specifications. In the current experimental setup only keyboard

 It is.
 In  fact,  there is no relation between _graphic_ operations and
Expose events, and that fact is somehow  mentioned  both  in  de-
scription  of  WhenMapped hint in CreateWindow request and in de-
scription of Expose operation itself.

> events are in the event mask and it's a little bit surprising that the
> graphic operation has an effect only after a keyboard event has been
> received.

 It is not.
 You get your results just by coincidence.



[skipped]

> >>the padding bytes at the end. Now I really made it to open a window and
> >  You  have specs of MIT Magic Cookie? You lucky guy, I don't have
> >this one.
> 
> It just needed some script "playing" the server to find out about the
> correct padding which usually should coincide with the terminating C string
> null byte.

 It does not (see another my message).

[skipped]

> core protocol requests to receive those mappings for the current maps in
> effect are ignored by the server.

 No.


[skipped]

> 
> >>finally deliver the protocol specifications where these kinds of
> >>interactions are layed out? Or some up to date updates on the core
> >>protocol? But as I have heard the X server doesn't even know about all
> >>registered extensions anymore - at least on Ubuntu with Unity one of
> >>the first events to be received was an impossible operation code of 192
> >>which wasn't reported by xdpyinfo to belong to any registered
> >  Extension  opcodes  assigned  by server at QueryExtension reply,
> >you should get that bytestream and find the extension  name  from
> >there. The number 192 may mean anything.
> 
> The QueryExtension request isn't implemented in the experimental setup right
> now but as stated /xdpyinfo/ didn't report that operation code.

 Bag my pardon: missed the word "Event" in you description.
 The  192 event is synthetic event with code 64, and I don't know
what it should mean. Mostly because never interested in possibil-
ity of bogus events -- just drop them.

> 
> 
> >>extension. The current state of X11 is a bit puzzling: it when works
> >  Yes,  the  protocol is not trivial. But it is consistent and core is
> >well-documented.
> >
> >  There are some features or extensions which lacks  proper  docu-
> >mentation  (MIT-MAGIC-COOKIE-1  authentication, RENDER extension,
> >NV-GLX extension) but in fact all of them is crap, and you should
> >probably get rid of it.
> 
> The core protocol is trivial - just not well documented. ;-) The XKB

 Well, we have different opinions on this.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X Core Protocol Scheme

[Ilya Anfimov]

On Sat, Dec 12, 2015 at 10:17:56AM +0100, Michael Titke wrote:

[skipped]

>The first surprise was the "magic" of the MIT Magic Cookie which needs
>that little deviation from the protocol encoding where you have to put
>the padding bytes at the end. Now I really made it to open a window and

 BTW,  protocol  specifies that MIT-MAGIC-COOKIE-1 authentication
string requires two bytes of padding, don't know why you  are  OK
with one -- probably, miss-by-one somewhere else.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X Core Protocol Scheme

[Ilya Anfimov]

On Sat, Dec 12, 2015 at 10:17:56AM +0100, Michael Titke wrote:

 BTW, you could get CLX as the base for your work -- it is common
lisp, not scheme, but it is well-written, it works, and,  consid-
ering   possibilities   of   automatically   transforming  source
code,  porting should be straightforward.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X Core Protocol Scheme

[Ilya Anfimov]

On Sat, Dec 12, 2015 at 10:17:56AM +0100, Michael Titke wrote:

 Good day!

 First, quoting looks like you had posted some letters before the
one I'm replying, but I didn't see it in my mailbox or x.org list
archives,  so I will answer just to text in the letter written at
2015-12-12 10:17:56 +0100.


>Now the arc drawing part works: it needed a little change of the
>"implemented protocol" or request sequence:
>First map the window, second listen for events. Third draw the arc.
>That was the third round after authentication and putting a window on
>the screen. It would be nice if these sequences were  documented as

 Generally,  the exact sequence isn't that important. If you want
a consistent picture, and don't want to redraw 50 times a second,
then  you  should  draw  every time you received Expose event, no
matter what you drawed before and even no matter of  your  knowl-
edge of the mapped state.

(Hmm,  sorry for my english and for my descriptive abilities: ev-
ery time doesn't mean  that after receiving 2 or 5 or  10  Expose
events  in a single packet you should redraw the same 10 times in
a raw. Just redraw once at least all the requested regions  imme-
diately after some Expose events received).

 This is described in Expose event paragraph in section 11 of the
protocol specification.

btw, this automatically means  that  you  should  receive  Expose
events  on  the  window you want to draw and therefore select Ex-
posure in the event mask at a window creation.

>part of the protocol. For now it remembers me that I need to change the
>low level IO routines to then buffer the graphics operations in a
>drawing graph and connect it the repaint events and ...
>(X-polifill-arc X (second v) (second g) 150 200 60 60 (* 10 64) (* 350
>64)) => 24  ; doesn't appear
>(X-map-window X (second v)) => 8
>(X-control X) => Window #"254 255 31 4" received a key event #"9" down.
>escaping-X-control
>VSI> (X-polifill-arc X (second v) (second g) 150 200 60 60 (* 10 64) (*
>350 64))  ; OK appears
>(X-polifill-arc X (second v) (second g) 150 200 60 60 (* 10 64) (* 350
>64)) => 24
>VSI> (X-control X)
>...
>VSI:
>[1]https://code.launchpad.net/~michael-tiedtke-i/viper-system-interface
>/alfa
> 
>On 11/12/2015 22:02, Michael Titke wrote:
> 
>Hello!
>As part of a first incursion into the possibility to implementing
>native support for X starting from the wire protocol (w/o any Xlib/XCB
>support) I ran into a couple of situations where documentation didn't
>match implementation.
>The first surprise was the "magic" of the MIT Magic Cookie which needs
>that little deviation from the protocol encoding where you have to put
>the padding bytes at the end. Now I really made it to open a window and

 You  have specs of MIT Magic Cookie? You lucky guy, I don't have
this one.

>receive key codes destined for it but no keysyms as the request for the
>keyboard mappings is silently ignored. The XKB extension as far as I
>understand it essentially replaced that? But there is no addendum to
>core protocol specifications.

 No,  XKB  is  not  strictly  required. The next log supposes you
fixed your issues and successfully receiving keyboard events.

>The next round was about creating a circle: somehow I found out that
>another map request on the window was needed to see the respective

 The  fact  that  the newly created window is unmapped is pointed
out in the first sentence of CreateWindow description.

>errors due to simple mistakes during the preparation of the request and
>some misleading protocol encoding which states 3+3n for the request
>length.

 Didn't  see  any  misleadings  here. Request length is specified
consistently across the entire Requests section, and this meaning
is the only possible if you understand paragraph "Request Format"
in Chapter 1.
 Moreover, it is self-evident when you try to calculate that  re-
quest length by hand against fields byte length values.

>
>(define X (X-connection)) => #
>(define v (X-create-window X 50 50 300 400)) => #
>v => (44 #"254 255 255 3")
>(X-map-window X (second v)) => 8
>(define g (X-create-gc X (second v))) => #
>g => (16 #"253 255 255 3")
>(X-polifill-arc X (second v) (second g) 150 200 100 100 (* 170 64) (*
>180 64)) => 24
>(X-map-window X (second v)) => 8
>(X-control X) => VSI SCA/X: unhandled error: Length#"0 16 4 0  253 255
>255 3  0 0 71 0  0
>0 0 0  0 0 0 0  0 0 0 0  0 0 0 0  0 0 0 0"
>#
>
>My question is: will this continue like this? Are there any plans to

 I hope, yes.

>finally deliver the protocol specifications where these kinds of
>interactions are layed out? Or some up to date updates on the core
>protocol? But as I have heard the X server doesn't even know about all
>registered extensions anymore - at least on Ubuntu with Unity one of
>   

Re: Making xset stick on a secondary X session

[Ilya Anfimov]

On Thu, Oct 15, 2015 at 08:54:20AM +1000, Peter Hutterer wrote:
> On Wed, Oct 14, 2015 at 10:01:42AM -0700, Alan Coopersmith wrote:
> > On 10/14/15 08:00 AM, Ilya Anfimov wrote:
> > >  Looks  like  xset  r  rate  works only when the server is active
> > >(i.e.  on the active virtual console). This should be reported as
> > >bug  IMHO, however your configuration should work when run as the
> > >only X-server.
> > 
> > Oh, that's a different issue - keyboard settings are reset when VT
> > switching - I thought there was an open bug on the general issue,
> > but can only find bugs on specific symptoms at the moment, such as:
> > https://bugs.freedesktop.org/show_bug.cgi?id=25801
> 
> This is intentional (fsvo intentional). VT-switching disables
> all devices and re-enables them when you come back. Devices come back with
> their default settings (read: xorg.conf settings) as if they were
 
 In fact, no. 'xset r rate' settings, when issued on active
X-server, stays just fine after VT switch to another console
and back.
 Every running server have it's own independent rate.

> unplugged/replugged, and that includes the keyboard repeat rate.
> 
> Cheers,
>Peter
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Making xset stick on a secondary X session

[Ilya Anfimov]

On Wed, Oct 14, 2015 at 10:01:42AM -0700, Alan Coopersmith wrote:
> On 10/14/15 08:00 AM, Ilya Anfimov wrote:
> >  Looks  like  xset  r  rate  works only when the server is active
> >(i.e.  on the active virtual console). This should be reported as
> >bug  IMHO, however your configuration should work when run as the
> >only X-server.
> 
> Oh, that's a different issue - keyboard settings are reset when VT
> switching - I thought there was an open bug on the general issue,
> but can only find bugs on specific symptoms at the moment, such as:
> https://bugs.freedesktop.org/show_bug.cgi?id=25801

 btw,  checked  it  with  xset  q  --  it is really reset when VT
switching!
 I mean, with server :0 active, I put xset r rate 150 50 ; xset q
to  :1  display,  and  it reported correct delay/rate 150 50. But
when I switch to :1 display, settings reset to old ones,  xset  q
reports 500/30, and it visually really 500/30, and after
return to active server :0 and queried :1 -- it remains 500/30.

 When  setting  rate  and delay on active server -- it saved just
fine, xset q reports correct answer after any change  to  any  VT
and  back,  and I have different settings on different servers as
expected.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Finding the cursor

[Ilya Anfimov]

On Wed, Oct 14, 2015 at 06:32:52PM +0200, Thomas L?bking wrote:
> On Mittwoch, 14. Oktober 2015 11:57:22 CEST, Ilya Anfimov wrote:
> 
> > However,  exactly  enlarging cursor shape or changing it's color
> >is a tough task -- as there is no easy way to get current  cursor
> >in X11.
> 
> Like eg. XFixesGetCursorImage(dpy), resp. xcb_xfixes_get_cursor_image_*

 Thanks. I've really forgot to check this extension (probably be-
cause I never liked it's idea).

 This should be usable just fine, despite  the  fact  that  rein-
stalling  old  cursor  as  newly-created pixmap cursor instead of
setting old CURSOR resource is a bit ugly.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Making xset stick on a secondary X session

[Ilya Anfimov]

On Wed, Oct 14, 2015 at 03:24:15PM +0800, Tony Mobily wrote:
>Hi,
>I tried again. I am starting to doubt that xset works properly!
>I did:
>$ export DISPLAY=:1
>$ sudo X :1 -noreset &
>$ xeyes &
>$ xterm &
>I can then confirm that xset has no effect on the running X:
>$ xset r rate 50 150
>No difference in the repeat rate.
>However, if you run the command on the terminal within :1, it will work
>(as expected).
>It really looks like xset will only work if run within the server
>itself... but why? Should I report this as a bug? (it's really easy to
>reproduce)

 Confirming, reproduced, debian/jessie, X -version
X.Org X Server 1.16.4
Release Date: 2014-12-20

 Looks  like  xset  r  rate  works only when the server is active
(i.e.  on the active virtual console). This should be reported as
bug  IMHO, however your configuration should work when run as the
only X-server.


___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Finding the cursor

[Ilya Anfimov]

On Fri, Oct 09, 2015 at 10:33:23PM -0400, Alan Corey wrote:
> I don't think I posted this before.
> 
> The cursor changes depending what it's over, and if you've got
> something like an 1920x1080 screen full of mostly rxvt windows then
> most of the time it's an I-beam.  That can be hard to spot if you've
> looked away or been away.  MS Windows, XP at least, has an option to
> go to a big cursor if you do something like hold down a ctrl key by
> itself for more than 2 seconds.  The activating keystroke could be
> different but is there an easy way to do that with X?  Something so
> the application-specified cursor gets overridden temporarily and you
> get a cursor that jumps out at you?  Big, animated, flashing,
> something that doesn't blend into the desktop?  Then back to normal
> once you let go of that key.
> 
> I spend about 99% of my time in X these days, there isn't much I'd
> change.  Window manager of choice is rxvt, OS is OpenBSD.

 It  looks like GNOME creates new animated window at cursor loca-
tion. This should be easy to implement  in  independent  app  (or
just use oneko as a substitution).

 However,  exactly  enlarging cursor shape or changing it's color
is a tough task -- as there is no easy way to get current  cursor
in X11.
 Someone  could  try  to use RECORD extension to catch all create
cursor and set window attributes calls, but this is extremely ug-
ly.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Making xset stick on a secondary X session

[Ilya Anfimov]

On Tue, Oct 13, 2015 at 10:23:13PM +0800, Tony Mobily wrote:
>Hi,
> 
>I am running a second X server (:1) and then run the vnc client
>(tigervnc) over it in -fullscreen. I am having huge problems increasing
>the keyboard repeat rate and reducing the keyboard delay for that X
>server.
> 
>To see what I mean, simply run another X server:
> sudo X :1 &
> 
>The blank, empty X server will be there
> 
>Then go back to the "main" xserver, and run:
> export DISPLAY=:1
> xterm
> 
>At this point, the repeat is average and the delay is long--ish (the
>default). Now run within that xterm:
> xset r rate 150 50
> 
>The keyboard repeat rate and delay are adjusted. Great! CTRL-D and exit
>that term. Go back to the "main" X session, and type again:
> xterm
> 
>The new repeat/delay settings are gone (?!?!?!), keyboard is slow/delay
>is long-ish again!
> 
>Running xset r rate 150 50 from the "main" X server. even with
>DISPLAY=:1,  still won't change the keyboard rate for the second :1
>server.
> 
>This is a bugger, since I need to decide the repeat rate and the delay
>for that second X server ':1', since I will run the xvnc client in
>-fullscreen mode -- and I can't find a way of setting that X server :1
>so that the repeat/delay are what I need them to be.
> 
>Help?

 You could pass -noreset option to X or start some invisible non-
disturbing X client to prevent X server from restarting.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Color Management

[Ilya Anfimov]

On Mon, Sep 21, 2015 at 07:26:38PM +0200, Martin Kaffanke wrote:
> Hi there, 
> 
> Is there a way to make colors on the display looking the same as on the 
> printer, by printing a Page and compare the screen on sight? 

 Usually  there  is some way, but there is more than one and each
one is non-trivial. There is a good introduction on wikipedia:

   https://en.wikipedia.org/wiki/Linux_color_management

> 
> Martin 
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s