sharplispers / clx Goto Github PK

(ql version: clx-20180711-git) Related to issue #104, it is no longer possible to pass arbitrary initialization parameters to xlib constructors when creating the standard objects (fonts, windows, etc.)

The old xlib class system mapped all class slots to a &key in the constructor lambda list, unless that feature was explicitly turned off in the class definition.

(defmacro def-clx-class ((name &rest options) &body slots)
         ...
		    (if (eq constructor-args t)
			`(defun ,constructor (&rest args)
			   (apply #',(closintern 'make-instance)
				  ',name args))

Note, that in the new code, most classes work fine since slots mentioned in the documentation are explicitly given :initargs to match the documentation. But this breaks some code that depends on incompletely documented features like wm-hints. In cases like that, those values must be set after object creation. An example of code that used to work.

(xlib:make-wm-hints :input :on :initial-state :normal)

Thanks for adopting clx. The FreeBSD clx package has been using https://common-lisp.net/~abridgewater/dist/clx/clx-0.7.4.tgz, but we would like to switch to your release. One issue is that your newer code is versioned lower. Our packaging tools have ways to deal with a newer release with a lower version, but there are downsides. Do you have plans to tag a new version in the not-too-distant future? That would be helpful for us to get your code package.

The implementation of render-query-picture-formats calls the function BYTE on the colour values for the picture format. Here's the relevant code:

(make-picture-format
               :display display
               :id         (card32-get (+ off 0))
               :type       (member8-get (+ off 4) :indexed :direct)
               :depth      (card8-get   (+ off 5))
               :red-byte   (byte (integer-length (card16-get (+ off 10)))
                                 (card16-get (+ off 8)))
               :green-byte (byte (integer-length (card16-get (+ off 14)))
                                 (card16-get (+ off 12)))
               :blue-byte  (byte (integer-length (card16-get (+ off 18)))
                                 (card16-get (+ off 16)))
               :alpha-byte (byte (integer-length (card16-get (+ off 22)))
                                 (card16-get (+ off 20)))
               :colormap   (let ((cmid (card32-get (+ off 24))))
                             (unless (zerop cmid)
                               (lookup-colormap display cmid))))

As far as I can tell, there shouldn't be a call to BYTE in those arguments.

This looks like it might be important:

;Compiler warnings for "home:lisp;sharplispers-clx;dep-openmcl.lisp.newest" :
;   In XLIB::HOST-ADDRESS: Undefined function CCL::HOST-AS-INET-HOST

CLX clashes with cl-opengl because CLX defines a gl package and cl-opengl nicknames the package cl-opengl with the name gl.

@cbaggers suggested that having CLX depend on cl-opengl could make sense to resolve this.

[https://github.com/cbaggers/cepl/issues/56]

There's a weird thing happening w/ recompiling vs. just loading CLX.

On a fresh SBCL 1.3.19 the following happens for me:

Rebuilding CLX:

CL-USER> (asdf:load-system :clx :force t)
T
CL-USER> xlib::*gcontext-extensions*
(#(:TRAPEZOID-ALIGNMENT :X XLIB::|Internal-Set-GCONTEXT-TRAPEZOID-ALIGNMENT|
   XLIB::|Internal-Copy-GCONTEXT-TRAPEZOID-ALIGNMENT|))

But after restarting and loading without rebuilding:

CL-USER> (asdf:load-system :clx)
T
CL-USER> xlib::*gcontext-extensions*
NIL

In both cases:

CL-USER> (describe 'XLIB::|Internal-Copy-GCONTEXT-TRAPEZOID-ALIGNMENT|)
XLIB::|Internal-Copy-GCONTEXT-TRAPEZOID-ALIGNMENT|
  [symbol]
; No value

i.e. the symbol is in particular not fbound. The entry in *gcontext-extensions* is, however, used later by CLX via funcall, resulting in the reported error.

The problem disappears (i.e. *gcontext-extensions* stays NIL after recompiling CLX) when I comment out loading demo/zoid.lisp and test/trapezoid.lisp in the ASD file, which suggests it's the zoid demo that's interfering with compilation of the library.

Hello,
I was unable to find the LICENSE file for this program. Please consider adding one so that this can be packaged in various GNU/Linux distros.

List of GPL compatible licenses:
https://www.gnu.org/licenses/license-list.html

(xtest:fake-motion-event (open-default-display) 0 0)

This won't work, doesn't move my mouse to the corner.

Am I missing something?

Steps to reproduce

CL-USER> (ql:quickload 'clx/test)
*snip*
CL-USER> (in-package #:xlib)
#<PACKAGE "XLIB">
XLIB> (clx-test-utils:with-default-display display
        (let* ((root-window (screen-root (display-default-screen display)))
               (valid-pixmap (create-pixmap :width 100
                                            :height 100
                                            :depth 1
                                            :drawable root-window))
               (context (create-gcontext :drawable root-window)))
          (gcontext-clip-mask context)                      ; This line succeeds.
          (setf (gcontext-clip-mask context) valid-pixmap)  ; This line succeeds.
          (gcontext-clip-mask context)))                    ; This line fails.

Note that according to the documentation, the pixmap I am trying to apply here is valid.

If a pixmap is specified as the clip-mask, it must have depth one and the same
root as the specified graphics context.

The error

The value
  23068673
is not of type
  (INTEGER 0 0)
when binding #:G2
   [Condition of type TYPE-ERROR]

Restarts:
 0: [RETRY] Retry SLIME REPL evaluation request.
 1: [*ABORT] Return to SLIME's top level.
 2: [ABORT] abort thread (#<THREAD "repl-thread" RUNNING {1007F3FF83}>)

Backtrace:
  0: (GCONTEXT-CLIP-MASK #<GCONTEXT :0 23068674>)
  1: ((LAMBDA ()))
  2: (SB-INT:SIMPLE-EVAL-IN-LEXENV (CLX-TEST-UTILS:WITH-DEFAULT-DISPLAY DISPLAY (LET* (# # #) (GCONTEXT-CLIP-MASK CONTEXT) (SETF # VALID-PIXMAP) (GCONTEXT-CLIP-MASK CONTEXT))) #<NULL-LEXENV>)
  3: (EVAL (CLX-TEST-UTILS:WITH-DEFAULT-DISPLAY DISPLAY (LET* (# # #) (GCONTEXT-CLIP-MASK CONTEXT) (SETF # VALID-PIXMAP) (GCONTEXT-CLIP-MASK CONTEXT))))

I pulled origin/master and my WM breaks and says XLIB:CURSOR-DISPLAY undefined, the window manager doesn't call XLIB:CURSOR-DISPLAY directly so I suppose it's a problem of CLX. Switch to stable branch works fine.

I've written a long winded explanation here:
https://github.com/stumpwm/stumpwm/wiki/International-Input-and-XKeyboard-Development

In short, I want to help solve this problem in a permanent way. This will mean having CLX support the xkeyboard extension. I have opened an issue to merge clx-xkeyboard into this repo:
filonenko-mikhail/clx-xkeyboard#1

I am volunteering to coordinate the overall effort of developing XKB in CLX. I'm reaching out to see how you would like me to proceed. My nominal plan is to host a fork of sharplispers/clx, implement and test the extension, and when it is ready merge it back into sharplispers/clx.

Alternatively I'm happy to be a point of contact for coordinating contributions and individual contributions can be made as PRs directly to sharplispers/clx. Please let me know the best way to proceed.

EDIT: Changed url to an evergreen one independent of my personal github.

When I try to run xlib:open-font with "9x15bold", such as in the following snippet

(defun hello-world (width height &optional (host ""))
  (let* ((display (xlib:open-display host))
     (screen (first (xlib:display-roots display)))
     (black (xlib:screen-black-pixel screen))
     (white (xlib:screen-white-pixel screen))
     (root-window (xlib:screen-root screen))
     (grackon (xlib:create-gcontext
           :drawable root-window
           :font "9x15bold"
           :foreground white
           :background black))
     (my-window (xlib:create-window
             :parent root-window
             :x 0
             :y 0
             :width width
             :height height
             :background black
             :event-mask (xlib:make-event-mask :exposure
                               :button-press))))
    (describe (xlib:gcontext-font grackon))
    (xlib:map-window my-window)
    (xlib:event-case (display :force-output-p t
                  :discard-p t)
      (:exposure (count)
     (when (zerop count)
       (xlib:draw-glyphs
         my-window
         grackon
         20 50
         "Hello World!"))
     nil)
      (:button-press () t))
    (xlib:destroy-window my-window)
    (xlib:close-display display)))

I get the following error:

FONT-ERROR in current request  Code 47.0 [QueryFont] ID #x3600002
   [Condition of type XLIB:FONT-ERROR]

Restarts:
 0: [RETRY] Retry SLIME REPL evaluation request.
 1: [*ABORT] Return to SLIME's top level.
 2: [ABORT] Abort thread (#<THREAD "repl-thread" RUNNING {1009CD80B3}>)

Backtrace:
  0: (XLIB::X-ERROR XLIB:FONT-ERROR :DISPLAY #<XLIB:DISPLAY :0 (The X.Org Foundation R11603000)> :ERROR-KEY XLIB:FONT-ERROR :ASYNCHRONOUS NIL :CURRENT-SEQUENCE 12 :RESOURCE-ID 56623106 :MAJOR 47 :MINOR 0 :..
  1: (XLIB::READ-REPLY #<XLIB:DISPLAY :0 (The X.Org Foundation R11603000)> #S(XLIB::PENDING-COMMAND :SEQUENCE 12 :REPLY-BUFFER NIL :PROCESS #<SB-THREAD:THREAD "repl-thread" RUNNING {1009CD80B3}> :NEXT NIL)..
      Locals:
        DISPLAY = #<XLIB:DISPLAY :0 (The X.Org Foundation R11603000)>
        PENDING-COMMAND = #S(XLIB::PENDING-COMMAND :SEQUENCE 12 :REPLY-BUFFER NIL :PROCESS #<SB-THREAD:THREAD "repl-thread" RUNNING {1009CD80B3}> :NEXT NIL)
        REPLY-BUFFER = #S(XLIB::REPLY-BUFFER ..)
  2: (XLIB::QUERY-FONT #<XLIB:FONT 9x15bold :0 56623106>)
      Locals:
        .DISPLAY. = #<XLIB:DISPLAY :0 (The X.Org Foundation R11603000)>
        .PENDING-COMMAND. = #S(XLIB::PENDING-COMMAND :SEQUENCE 12 :REPLY-BUFFER NIL :PROCESS #<SB-THREAD:THREAD "repl-thread" RUNNING {1009CD80B3}> :NEXT NIL)
        .REPLY-BUFFER. = NIL
        DISPLAY = #<XLIB:DISPLAY :0 (The X.Org Foundation R11603000)>
        FONT = #<XLIB:FONT 9x15bold :0 56623106>
        FONT-ID = 56623106
        FONT-INFO = NIL
        PROPS = NIL
  3: (XLIB:OPEN-FONT #<XLIB:DISPLAY :0 (The X.Org Foundation R11603000)> "9x15bold")
      Locals:
        DISPLAY = #<XLIB:DISPLAY :0 (The X.Org Foundation R11603000)>
        FONT = #<XLIB:FONT 9x15bold :0 56623106>
        FONT-ID = 56623106
        NAME = "9x15bold"
        NAME-STRING = "9x15bold"
  4: (XLIB::SET-GCONTEXT-FONT #<XLIB:GCONTEXT :0 56623105> "9x15bold")
  5: (XLIB:CREATE-GCONTEXT :DRAWABLE #<XLIB:WINDOW :0 AD> :FONT "9x15bold" :FOREGROUND 16777215 :BACKGROUND 0)
  6: (XLIB:CREATE-GCONTEXT :DRAWABLE #<XLIB:WINDOW :0 AD> :FONT "9x15bold" :FOREGROUND 16777215 :BACKGROUND 0) [more,optional]
  7: (XLIB:CREATE-GCONTEXT) [tl,external]
  8: (HELLO-WORLD 900 400 "")

However, running (xlib:list-fonts stumpwm::*display* "9x15bold") returns

(#<XLIB:FONT -misc-fixed-bold-r-normal--15-140-75-75-c-90-iso8859-1 :0>
 #<XLIB:FONT -misc-fixed-bold-r-normal--15-140-75-75-c-90-iso8859-1 :0>)

Running hello-world with the font set to -misc-fixed-bold-r-normal--15-140-75-75-c-90-iso8859-1 works properly. Running (xlib::display-font-cache stumpwm::*display*) returns

(#<XLIB:FONT 9x15 :0 4194888> #<XLIB:FONT 9x15bold :0 4194644>
 #<XLIB:FONT nil :0 4194638> #<XLIB:FONT cursor :0 4194320>
 #<XLIB:FONT
   -xos4-terminus-bold-r-normal--12-120-72-72-c-60-iso8859-1 :0 4194313>)

But the second item, theoretically associated with 9x15bold, contains no FONT-INFO-INTERNAL.

I'm probably missing something here, so please let me know what other information might be helpful.

Thank you.

While #53 is fixed by #54, clx doesn't pick the new keyboards at all (even if the keyboard is different at start than us it is chosen), so regional characters can't be typed. Steps to reproduce:

1. Set keyboard for language with regional characters: setxkbmap pl
2. Verify that you can insert regional characters (ALT-RIGHT + s should produce
3. Start climacs (or anything what uses clx keyboard input)
4. Try to insert regional character in climacs

This issue is related to McCLIM/McCLIM#35 .

Would you please add a :description to CLX's system definition?

When running on allegro, package.lisp tries to use the cltl1 package. But my copy of Allegro 10.0 complains that this package does not exist.

README has a lot of stuff about asdf-install that probably isn't all that relevant any more.

Steps to reproduce:

1. Set keyboard layout to English before starting lisp
   setxkbmap -layout us
2. Start any application using clx (for instance climacs)

(eval-when (:load-toplevel :compile-toplevel :execute)
  (ql:quickload 'climacs))
(climacs:climacs)

1. Type a few characters in climacs (layout is qwerty)
2. Change layout from the console
   setxkbmap -layout fr
3. Type a few more characters in climacs (layout is still qwerty)

How to fix:

diff --git a/translate.lisp b/translate.lisp
index 0b0d7a8..64bc183 100644
--- a/translate.lisp
+++ b/translate.lisp
@@ -279,8 +279,7 @@
 (defun display-keyboard-mapping (display)
   (declare (type display display))
   (declare (clx-values (simple-array keysym (display-max-keycode keysyms-per-keycode))))
-  (or (display-keysym-mapping display)
-      (setf (display-keysym-mapping display) (keyboard-mapping display))))
+  (setf (display-keysym-mapping display) (keyboard-mapping display)))

 (defun keycode->keysym (display keycode keysym-index)
   (declare (type display display)

Fix proposed in: McCLIM/McCLIM#35

system
Xorg 1.11.3/protocol 11, amd x86_64, nvidia 290.10-2
When I load demo/gl-test.lisp and call (gl-test:test #'gl-test::gears :host "" :display 0), I have following error.

Asynchronous MATCH-ERROR in request 16 (last request was 18) Code 1.0 [CreateWindow]
[Condition of type XLIB:MATCH-ERROR]

Restarts:
...

Backtrace:
0: (XLIB::READ-ERROR-INPUT ..)
1: (XLIB::READ-INPUT ..)
2: (XLIB::READ-REPLY # #)
3: (XLIB::QUERY-FONT #<XLIB:FONT fixed :0 35651587>)
4: (XLIB:OPEN-FONT #<XLIB:DISPLAY :0 (The X.Org Foundation R11103000)> "fixed")
5: (GL-TEST:TEST # :HOST "" :DISPLAY 0 :WIDTH 200 :HEIGHT 200)
.....

I'm trying to type Compose key sequences in StumpWM, and see that they don't work — but it does recognise that it's pressed (as the SunCompose key). I think that the right place to handle this is in CLX, not in xkeyboard.

I'm willing to take a cut at implementing this: I assume that EVENT-LOOP is the right place to get started. Does that sound right?

I tried to use make-event-handlers to generate handlers array for process-event.
I know, it isn't documented (yet), but:

(xlib:make-event-handlers :default nil)

ARRAY is a bad type specifier for sequences.

4: (MAKE-SEQUENCE ARRAY 64 :INITIAL-ELEMENT NIL)

Discrepancy in types is due to

input.lisp:1199
	(defun make-event-handlers (&key (type 'array) default)

Or my usage / understanding is wrong?

Currently somes files in extensions directory have an exact duplicate in the top level directory. This seems to be related to #15 and its reversal (#25). Looking at clx.asd all of the duplicates are loaded from the extension directory so I think the appropriate solution would be to delete the ones in the top level directory

List of Duplicate files

• big-requests
• xvidmode
• xtest
• xrender
• xinerama
• shape
• screensaver
• gl
• glx

We have two default-keysym-translate implementations in the codebase.

;;-----------------------------------------------------------------------------
;; DEFAULT-KEYSYM-TRANSLATE
;;-----------------------------------------------------------------------------

;;; If object is a character, char-bits are set from state.
;;;
;;; [the following isn't implemented (should it be?)]
;;; If object is a list, it is an alist with entries:
;;; (base-char [modifiers] [mask-modifiers])
;;; When MODIFIERS are specified, this character translation
;;; will only take effect when the specified modifiers are pressed.
;;; MASK-MODIFIERS can be used to specify a set of modifiers to ignore.
;;; When MASK-MODIFIERS is missing, all other modifiers are ignored.
;;; In ambiguous cases, the most specific translation is used.

Function is used in translate.lisp:

• mentioned in comment for define-keysym function
• used in keysym->characteras a fallback when (keysym-mapping-translate mapping) doesn't exist (which is called from keycode->character).

First one is dummy (all except allegro and lispm):

(defun default-keysym-translate (display state object)
  (declare (type display display)
       (type card16 state)
       (type t object)
       (ignore display state)
       (clx-values t))
  object)

and the second one (which is defined only on allegro and lispm):

(defun default-keysym-translate (display state object)
  (declare (type display display)
       (type card16 state)
       (type t object)
       (clx-values t)
       (special left-meta-keysym right-meta-keysym
            left-super-keysym right-super-keysym
            left-hyper-keysym right-hyper-keysym))
  (when (characterp object)
    (when (logbitp (position :control +state-mask-vector+) state)
      (setf (char-bit object :control) 1))
    (when (or (state-keysymp display state left-meta-keysym)
          (state-keysymp display state right-meta-keysym))
      (setf (char-bit object :meta) 1))
    (when (or (state-keysymp display state left-super-keysym)
          (state-keysymp display state right-super-keysym))
      (setf (char-bit object :super) 1))
    (when (or (state-keysymp display state left-hyper-keysym)
          (state-keysymp display state right-hyper-keysym))
      (setf (char-bit object :hyper) 1)))
  object)

Which implementation is correct and do we want to have different behaviour for different implementations with this regard?

This parts of code are possibly related to: #55

I want to package StumpWM for Void Linux, and Stump depends on CLX.
Void tends to eschew packaging git snapshots.
Any chance of getting a release for CLX? Please?

Any plans of bumping the package version to 0.7.5?

Stumpwm Gentoo ebuild builds fine with the current master branch but fails with version 0.7.4. It would be easy for us if the version is bumped.

Thanks.

(ql version: clx-20180711-git) For every xlib 'class' that the the old def-clx-class macro used to create, a predicate function, e.g. foo-p would also be created unless it's creation was specifically suppressed in the class options.

(defmacro def-clx-class ((name &rest options) &body slots)
    ....
	  (when (eq predicate t)
	    (setf predicate (cintern name '-p)))

Some examples that used to work.

(xlib:window-p *application-window*)
(xlib:image-z-p  (xlib:get-image *application-window* :result-type 'image-xy :x x :y y :width width :height height))
(xlib:font-p (xlib:open-font *display* (first (xlib:list-font-names *display* "*"))))

How to reproduce (type in a repl to avoid problems with symbols):

(ql:quickload 'clim-listener)
(defun clim-user::crash (s)
  (climi::with-text-size (t s) (princ "?")))
(clim-listener:run-listener :new-process t)

Type in clim-listener: (crash 715) – connection gets crashed.

Analysis:

xrender extension calls directly write-image-z from the render-add-glyph without verifying whenever the request exceeds the max-request-length (put-image verifies, if the buffer may be rendered), what leads to the crash. Server can't be restarted. write-image-z is called inly from put-image and write-image-z.

Possible solutions:

1. validate the request length in render-add-glyph and signal an error if it's too large (simple, but not general enough).
2. embed validation in macro with-buffer-request – it has a benefit that new extensions (or "wild" calls to write-image-z and all other rendering functions will be validated, however I'm not sure yet how to do that – macrology there is strong).

While implementing parse-display and checking against XCB's test I found that in the case of decnet addresses CLX's xlib::get-default-display differs from XCB. In that it doesn't consider the colon as part of the host.

In CL

XCB/TESTS> (xlib::get-default-display "myws::0")
;; => ("myws" 0 0 :DECNET)

While in XCB host is myws: as you can see from the test c snippet below as well as from the test suite

Given that I know next to nothing about decnet I'm not 100% sure it is a bug in CLX, I'm inclined to believe their test suite.

// Compile it with:
// gcc scratch.c -o scratch -std=c99 -I/usr/include -I/usr/include/xcb/ -L/usr/lib/x86_64-linux-gnu -lc -lxcb
#include <stdlib.h>
#include <stdio.h>
#include <xcb.h>
#include <string.h>

int
main(int argc, char *argv[])
{
  int err;
  char *host = NULL;
  int display, screen;

  err = xcb_parse_display("myws::0", &host, &display, &screen);
  if (err == 0)
    perror("Failed to parse display");

  printf("Host: %s\n", host);

  return EXIT_SUCCESS;
}

Thanks

1. Build

clx.texinfo:7502: warning: @table has text but no @item
clx.texinfo:7605: warning: @table has text but no @item
clx.texinfo:481: warning: @pxref node name should not contain `:'
clx.texinfo:484: warning: @pxref node name should not contain `:'
clx.texinfo:904: warning: @pxref node name should not contain `:'
clx.texinfo:907: warning: @pxref node name should not contain `:'
clx.texinfo:911: warning: @pxref node name should not contain `:'
clx.texinfo:999: warning: @pxref node name should not contain `:'

2. Install
3. Loading this library

WARNING:
   compiling #<STATIC-FILE "clx" "NEWS"> completed without its input file #P"/usr/share/common-lisp/source/clx/NEWS"
WARNING:
   loading #<STATIC-FILE "clx" "NEWS"> completed without its input file #P"/usr/share/common-lisp/source/clx/NEWS"
WARNING:
   compiling #<STATIC-FILE "clx" "CHANGES"> completed without its input file #P"/usr/share/common-lisp/source/clx/CHANGES"
WARNING:
   loading #<STATIC-FILE "clx" "CHANGES"> completed without its input file #P"/usr/share/common-lisp/source/clx/CHANGES"
WARNING:
   compiling #<STATIC-FILE "clx" "README"> completed without its input file #P"/usr/share/common-lisp/source/clx/README"
WARNING:
   loading #<STATIC-FILE "clx" "README"> completed without its input file #P"/usr/share/common-lisp/source/clx/README"
WARNING:
   compiling #<STATIC-FILE "clx" "README-R5"> completed without its input file #P"/usr/share/common-lisp/source/clx/README-R5"
WARNING:
   loading #<STATIC-FILE "clx" "README-R5"> completed without its input file #P"/usr/share/common-lisp/source/clx/README-R5"
WARNING:
   compiling #<LEGACY-FILE "clx" "exclMakefile"> completed without its input file #P"/usr/share/common-lisp/source/clx/exclMakefile"
WARNING:
   loading #<LEGACY-FILE "clx" "exclMakefile"> completed without its input file #P"/usr/share/common-lisp/source/clx/exclMakefile"
WARNING:
   compiling #<LEGACY-FILE "clx" "exclREADME"> completed without its input file #P"/usr/share/common-lisp/source/clx/exclREADME"
WARNING:
   loading #<LEGACY-FILE "clx" "exclREADME"> completed without its input file #P"/usr/share/common-lisp/source/clx/exclREADME"
WARNING:
   compiling #<LEGACY-FILE "clx" "excldepc"> completed without its input file #P"/usr/share/common-lisp/source/clx/excldep.c"
WARNING:
   loading #<LEGACY-FILE "clx" "excldepc"> completed without its input file #P"/usr/share/common-lisp/source/clx/excldep.c"
WARNING:
   compiling #<LEGACY-FILE "clx" "socket"> completed without its input file #P"/usr/share/common-lisp/source/clx/socket.c"
WARNING:
   loading #<LEGACY-FILE "clx" "socket"> completed without its input file #P"/usr/share/common-lisp/source/clx/socket.c"
WARNING:
   compiling #<STATIC-FILE "clx" "manual" "clx.texinfo"> completed without its input file #P"/usr/share/common-lisp/source/clx/manual/clx.texinfo"
WARNING:
   loading #<STATIC-FILE "clx" "manual" "clx.texinfo"> completed without its input file #P"/usr/share/common-lisp/source/clx/manual/clx.texinfo"
#<ASDF/LISP-ACTION:LOAD-OP >
#<ASDF/PLAN:SEQUENTIAL-PLAN {10053B7D03}>

Though these files are in clx-git/src/clx-git/.

I get the following error when trying to run the gl-test demo:

Asynchronous VALUE-ERROR in request 39 (last request was 41)  Code 154.3 [GLX] Value 39.
   [Condition of type VALUE-ERROR]

Restarts:
 0: [CONTINUE] Ignore
 1: [RETRY] Retry SLIME REPL evaluation request.
 2: [*ABORT] Return to SLIME's top level.
 3: [ABORT] abort thread (#<THREAD "new-repl-thread" RUNNING {1002BB32B3}>)

Backtrace:
  0: (XLIB::READ-ERROR-INPUT #<DISPLAY :0 (Fedora Project R11804000)> 39 #S(XLIB::REPLY-BUFFER :SIZE 32 :IBUF8 #(0 2 39 0 39 0 ...) :NEXT NIL :DATA-SIZE 32) #<SB-THREAD:THREAD "new-repl-thread" RUNNING {10..
  1: (XLIB::READ-INPUT #<DISPLAY :0 (Fedora Project R11804000)> NIL NIL #<FUNCTION (LAMBDA (XLIB::PENDING-COMMAND) :IN XLIB::READ-REPLY) {1004F10D2B}> #S(XLIB::PENDING-COMMAND :SEQUENCE 41 :REPLY-BUFFER NI..
  2: (XLIB::READ-REPLY #<unavailable argument> #<unavailable argument>)
  3: (XLIB/GLX:MAKE-CURRENT #<WINDOW :0 2400002> #<XLIB/GLX::CONTEXT :0 37748741>)
  4: (TEST #<FUNCTION GEARS> :HOST "" :DISPLAY 0 :WIDTH 200 :HEIGHT 200)

Getting a crash from sunless sea on one of my PCs(not the other).

Caught 'The value
          4294967295
        is not of type
          (MOD 11)' at the top level. Please report this.
Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {1003436D93}>
0: (XLIB::DECODE-WM-SIZE-HINTS #(762 0 0 50215584 0 1022 747 1022 747 1022 747 0 0 ...))
1: (STUMPWM::GET-NORMALIZED-NORMAL-HINTS #<XLIB:WINDOW :0 1C00002>)
2: (STUMPWM::UPDATE-WINDOW-PROPERTIES #S(TILE-WINDOW "Sunless Sea" #x1C00002) :WM_NORMAL_HINTS)
3: (STUMPWM::HANDLE-EVENT :DISPLAY #<XLIB:DISPLAY :0 (The X.Org Foundation R11900000)> :EVENT-KEY :PROPERTY-NOTIFY :EVENT-CODE 28 :SEND-EVENT-P NIL :SEQUENCE 3537 :WINDOW #<XLIB:WINDOW :0 1C00002> :EVENT-WINDOW #<XLIB:WINDOW :0 1C00002> :ATOM :WM_NORMAL_HINTS :TIME 1346597 :STATE :NEW-VALUE)
4: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK :IN XLIB:PROCESS-EVENT))
5: ((FLET #:WITHOUT-INTERRUPTS-BODY-387 :IN SB-THREAD::CALL-WITH-RECURSIVE-LOCK))
6: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK #<CLOSURE (FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK :IN XLIB:PROCESS-EVENT) {7FFFF651724B}> #<SB-THREAD:MUTEX "CLX Event Lock" owner: #<SB-THREAD:THREAD "main thread" RUNNING {1003436D93}>> T NIL)
7: ((FLET SB-IMPL::TIMEOUT-BODY :IN XLIB:PROCESS-EVENT))
8: (XLIB:PROCESS-EVENT #<XLIB:DISPLAY :0 (The X.Org Foundation R11900000)> :HANDLER #<FUNCTION STUMPWM::HANDLE-EVENT> :TIMEOUT 0 :PEEK-P NIL :DISCARD-P NIL :FORCE-OUTPUT-P T)
9: ((FLET #:WITHOUT-INTERRUPTS-BODY-387 :IN SB-THREAD::CALL-WITH-RECURSIVE-LOCK))
10: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK #<CLOSURE (FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK :IN STUMPWM::DISPATCH-ALL) {7FFFF65176BB}> #<SB-THREAD:MUTEX "CLX Event Lock" owner: #<SB-THREAD:THREAD "main thread" RUNNING {1003436D93}>> T NIL)
11: ((FLET STUMPWM::DISPATCH-ALL :IN "/home/azra/git-repos/stumpwm/stumpwm.lisp") #<XLIB:DISPLAY :0 (The X.Org Foundation R11900000)>)
12: ((:METHOD IO-LOOP (STUMPWM::SBCL-IO-LOOP)) #<STUMPWM::SBCL-IO-LOOP {10059926E3}> :DESCRIPTION "StumpWM") [fast-method]
13: (STUMPWM::STUMPWM-INTERNAL-LOOP)
14: (STUMPWM::STUMPWM-INTERNAL ":0")
15: (STUMPWM ":0")
16: ((LAMBDA NIL :IN "/home/azra/git-repos/stumpwm/make-image.lisp"))
17: ((FLET #:WITHOUT-INTERRUPTS-BODY-90 :IN SB-EXT:SAVE-LISP-AND-DIE))
18: ((LABELS SB-IMPL::RESTART-LISP :IN SB-EXT:SAVE-LISP-AND-DIE))

Haven't found a fix for that one quite yet.

Vector responsible: #(762 0 0 50215584 0 1022 747 1022 747 1022 747 0 0 0 0 0 0 4294967295)

This base64 encoded .XAuthority file breaks read-xauth-entry. It's the 4th entry that breaks it.

steps to reproduce:

1. base64 decode this file and save it somewhere:

AAAABKwRqm4AATAAEk1JVC1NQUdJQy1DT09LSUUtMQAQFQ9gIfF5tJYrNva+w5NQlAAGABD+
gAAAAAAAAAIkVP/+mgWLAAEwABJNSVQtTUFHSUMtQ09PS0lFLTEAEBUPYCHxebSWKzb2vsOT
UJQBAAAEYXJjaAABMAASTUlULU1BR0lDLUNPT0tJRS0xABAVD2Ah8Xm0lis29r7Dk1CUAPwA
AAAAABJNSVQtTUFHSUMtQ09PS0lFLTEAEIeK/9/M6kB1huLzpUT9JtsAAAAEfwAAAQABMQAS
TUlULU1BR0lDLUNPT0tJRS0xABC5ScGiDUUsDC5hGetC+chmAQAABGFyY2gAATEAEk1JVC1N
QUdJQy1DT09LSUUtMQAQuUnBog1FLAwuYRnrQvnIZgAAAAR/AAABAAEyABJNSVQtTUFHSUMt
Q09PS0lFLTEAEBEIvywuCk6cr1hC7BzdJecBAAAEYXJjaAABMgASTUlULU1BR0lDLUNPT0tJ
RS0xABARCL8sLgpOnK9YQuwc3SXn

1. run this code. Point it to your decoded file:

(with-open-file (s #p"/path/to/xauthority-file" :element-type '(unsigned-byte 8)) (xlib::read-xauth-entry s) (xlib::read-xauth-entry s) (xlib::read-xauth-entry s) (xlib::read-xauth-entry s))

For something standardized like X, and for complex software projects in general, and especially for dynamically typed languages like Lisp, there ought to be a test suite.

Making test suites is big, complicated, and—to most—boring. But their existence is a basic tenet of good software.

Making a test suite for something graphical+networked is especially difficult.

Some initial steps:

• Pick a test framework. I'm partial to Fiasco. Many like FiveAM however.
• Add clx-test.asd and subsume currently existing test directory for test source code.
• Organize tests by sections of the standard being implemented, as well as auxiliary tests for (a) implementation-specific things and (b) utility/scaffolding/etc. code.

This is an old bug. See https://lists.gnu.org/archive/html/stumpwm-devel/2011-04/msg00009.html
and a report that someone fixed it in some implementation http://sourceforge.net/tracker/?func=detail&aid=3292605&group_id=1355&atid=101355.

I'm running into it specifically with some steam games. Patching my local build with the patch from the first link but it seems like it is some kind of workaround. Is there a better fix?

https://www.x.org/wiki/Development/Documentation/Multitouch/

https://github.com/tomaka/glutin/pull/573/files
https://unix.stackexchange.com/questions/146287/monitoring-events-keyboard-mouse-in-x
http://blog.qt.io/blog/2010/12/15/touching-the-x11-2/
https://gabrbedd.wordpress.com/2012/07/13/handling-xinput-2-multitouch-events-in-qt-part-1/

to see them in console, use this command: xinput test-xi2, normal xev will confuse touch and mouse.

These are the basics of a program I'm testing:

(defun grab-keys ()
  (let* ((screen (display-default-screen *display*))
         (root-window (screen-root screen)))
    (dolist (key *grab-keys*)
      (grab-key root-window (key->keycode key)
                :modifiers nil))))

(defun main ()
  (let ((*display* (open-display "")))
    (grab-keys)
    (loop (event-case (*display*)
            (:key-press
             (code)
             (format t "press: ~a~%" (keycode->key code))
             t)
            (:key-release
             (code)
             (format t "release: ~a~%" (keycode->key code))
             t)))))

I'm grabbing all of the letter keys. This works fine if I type keys individually. Once I start typing normally (rolling between keys), not all key release events are printed. For example, if I roll from j to k, k's release is not reported:

press: j
press: k
release: j

When there is overlap, I only get the first key's release. I'm not sure if I'm doing something incorrectly or if this is a problem somewhere else. Any ideas?

Because of 881c2fb manual fails to build.

clx.texinfo:11073: @pxref reference to nonexistent node `:mapping-notify'
clx.texinfo:11075: @pxref reference to nonexistent node `mapping-notify'

currently we include demo files in main distribution in demos module.

The link in README.md points to https://sharplispers.github.io/clx/ for the manual, but that page doesn't exist.

A user has reported a crash involving an authentication error preventing StumpWM from starting. A full back trace indicates that the problem is in CLX's handling of authenticating a session.

Further details here:
stumpwm/stumpwm#239

Let me know if you need anything else. I don't have a minimal working example, but could invest some effort if needed.

Allegro crashes trying to compile this CLX, with the following error:

attempt to call `XLIB::EXTENSION-EVENT-KEY-P' which is an
undefined function.

This happens because of a problem with the compile-time/load-time semantics, IIUC.

This is the problem, I believe:

1. extension-event-key-p is defined normally (i.e., with load time semantics) in input.lisp.
2. extension-event-key-p is forward referenced in the deftype for event-key in clx.lisp.
3. Allegro seems to eagerly check some properties of the event-key type. The crash occurs in compiling the defun for get-external-event-code, which declares its event parameter to be of type event-key. This causes Allegro to invoke an internal function called normalize-type, which in turn calls subtypep-specialist somehow on the definition of event-key, invoking extension-event-key-p, which is not yet defined.

EXTENSION-EVENT-KEY-P <-
  TYPEP <- (EXCL::SUBTYPEP-SPECIALIST 1 MEMBER) <-
  EXCL:NORMALIZE-TYPE <- COMP::PA-NEW-LISP-TEMP <-
  COMP::PA-PROCESS-LAMBDA-LIST <- COMP::PA-COMPILE-LAMBDA <-
  COMP::PA-START-COMPILE <- COMP::COMPILE-LE <-
  COMP::COMPILE-TO-LAPS <- COMP::COMPILE-FUNCTION-GROUP <-
  COMP::COMPILE-P-DEFUN <- COMP::COMPILE-PROCESS-FORM <-
  (FLET COMPILE-FILE EXCL::CONTINUATION) <- COMPILE-FILE <-
  COMP::WRAP-COMPILE-FILE <-
  ASDF/UTILITY:CALL-WITH-MUFFLED-CONDITIONS <-
  ASDF/LISP-BUILD::CALL-WITH-SAVED-DEFERRED-WARNINGS <-
  ASDF/PATHNAME:CALL-WITH-ENOUGH-PATHNAME <-
  ASDF/LISP-BUILD:COMPILE-FILE* <-

I was checking to see if this was Franz's fault, or CLX's, and I think it's CLX's. Here's the relevant bit from the deftype definition in the ANSI Spec:

If a deftype form appears as a top level form, the compiler must ensure that the name is recognized in subsequent type declarations. The programmer must ensure that the body of a deftype form can be evaluated at compile time if the name is referenced in subsequent type declarations.

This seems problematic, because it requires extension-event-key-p to be available at compile-time, which in turn means that the *extensions* variable must be defined at compile time, and....

I had a bash at fixing this, but the changes required were too substantial and touched too much code I didn't understand well. Hoping the solution is obvious to someone else.

Without testing, I think there's a latent bug in declare-event. The code is careful to avoid generating reads for pad fields in events when those have been declared with pad8 or pad16, but there's no corresponding avoidance for the pad32 type.

This came up in discussion with asvil on #lisp, who is implementing xkeyboard, which has pad fields in events.

I've approached this problem during work on McCLIM clx font part refactoring. It seems, that xlib:text-extents returns invalid values for arabic fonts (#<XLIB:FONT -arabic-newspaper-medium-r-normal--32-246-100-100-p-137-iso10646-1 :0 12583033>).

After digging a bit more, I've found, that local-text-extents returns invalid ascent/descent values for the font (i.e -32767). This is fixed, if we comment out local-text-extents and server-text-extents is always called (hack below).

Steps to reproduce:

1. Install xorg-fonts-misc (or arabic24.pcf.gz font from the preferred source)
2. Run font-selector demo from McCLIM)

(eval-when (:compile-toplevel :load-toplevel :execute)
  (ql:quickload 'clim-examples))
(clim-demo:demodemo)
;; pick font-selector demo

NB Arabic font won't be rendered even if we have sane ascent/descent values, but this seems to be a separate issue which I'm not sure where it belongs to, or if its a bug – it may be that Arabic font can't render ASCII characters – but the system doesn't crash, only text isn't rendered).

Hack correcting behaviour (but we should fix local-text-extents instead):

diff --git a/text.lisp b/text.lisp
index dcac272..743fbaa 100644
--- a/text.lisp
+++ b/text.lisp
@@ -165,7 +165,7 @@
              ((integerp new-font) (incf width (the int32 new-font))))

        (let (w a d l r)
-         (if (or (font-char-infos-internal font) (font-local-only-p font))
+         (if nil ;(or (font-char-infos-internal font) (font-local-only-p font))
              ;; Calculate text extents locally
              (progn
                (multiple-value-setq (w a d l r)
@@ -254,7 +254,7 @@
              ((integerp new-font) (incf width (the int32 new-font))))

        (incf width
-             (if (or (font-char-infos-internal font) (font-local-only-p font))
+             (if nil ;(or (font-char-infos-internal font) (font-local-only-p font))
                  (text-extents-local font wbuf 0 buf-end :width-only)
                (text-width-server font wbuf 0 buf-end)))
        (when (type? new-font 'font)

xlib:event-listen claims to block indefinitely if the local event queue is empty and timeout is nil, otherwise if the event queue is empty and timeout is not nil, it waits timeout number of seconds and then returns nil.

But, in reality xlib:event-listen treats timeout = 0 the same as timeout = nil This is unfortunate because it implies that checking the event queue could require the client to block for at least 1 second. An extremely long time in today's desktop world. Ideally the function would be rewritten, so that timeout was made nil by default, and explicitly passing the argument of timeout = 0 when calling the function would ensure that the function wouldn't block even if there was nothing on the queue.

(defun event-listen (display &optional (timeout nil))

     ....

    )

with the behavior of

=> (xlib:event-listen *display* 0)
nil

Given the extreme conservatism of CLX, and the fact that this behavior seems to have been in place for a long time, perhaps the better alternative would be to change the documentation to correspond to current behavior: timeout 0 is treated the same as nil, and that if a no 'blocking' operation is wanted the user should instead specify a very small rational or real number, e.g. (xlib:event-listen *display* 0.001)

These are guarded by a feature clx-ansi-common-lisp

Please consider adding :description, :author and :license information to your ASDF system(s). This will greatly help Quicklisp users and make it easier for them to report bugs.

More information:

http://blog.quicklisp.org/2015/05/looking-for-more-metadata.html
https://www.quicklisp.org

The function put-raw-image only allows to create XPutImage requests of a maximum length given by a 16-bit number. This corresponds e.g. to a 256x255x4 byte image and is quite limiting.

Bigger images could either be drawn using a multiple calls to XPutImage for sub-rectangles, or a single XPutImage request using the BIG-REQUESTS extension could be used. I think the first method is unnecessarily complicated. The latter I implemented in my own test code on https://github.com/plops/cl-pure-x11/blob/master/x.lisp This supports much larger images.

The function that constructs the request in my much more simple minded framework looks like this:

(defun put-image-big-req (img)
  (declare ((simple-array (unsigned-byte 8) 3) img))
  (destructuring-bind (h w c)
      (array-dimensions img)
   (let*((img1 (sb-ext:array-storage-vector img))
         (n (length img1))
         (p (pad n))) 
     (with-packet
       (card8 72)                       ; opcode
       (card8 2)                        ; format Z-pixmap
       (card16 0)                       ; length=0 => this is a big request
       (card32 (+ 7 (/ (+ n p) 4)))
       (card32 *window*)                ; window
       (card32 *gc*)
       (card16 w)
       (card16 h)
       (card16 0) ; dst-x
       (card16 0) ; dst-y
       (card8 0) ; left-pad
       (card8 24) ; depth
       (card16 0) ; unused
       )
     (write-sequence img1 *s*)
     (dotimes (i p)
       (write-byte 0 *s*))
     (force-output *s*))))

I tried to understand how CLX constructs its requests. Unfortunately I couldn't figure out how to write patch for CLX to create a request using a 32-bit length as the function above does.

Apparently the CCL folks removed a non-exported function that was used by the dep-openmcl.lisp file.

Here's a diff that seems to fix the resulting problem. Code is from clx-20150407-git.

nova:clx-20150407-git > diff -C 1 dep-openmcl.lisp~ dep-openmcl.lisp
*** dep-openmcl.lisp~   Wed Jul 29 09:49:09 2015
--- dep-openmcl.lisp    Wed Jul 29 09:58:31 2015
***************
*** 830,832 ****
      ((:internet nil 0)
!      (let* ((addr (ccl::htonl (ccl::host-as-inet-host host))))
         (cons :internet (list
--- 830,832 ----
      ((:internet nil 0)
!      (let* ((addr (ccl:lookup-hostname host)))
         (cons :internet (list

Note that formerly this part of the code lacked the ccl::htonl call, as below. Not sure what the status of the latest code is. This code is from clx-20141106-git

(defun host-address (host &optional (family :internet))
  ;; Return a list whose car is the family keyword (:internet :DECnet :Chaos)
  ;; and cdr is a list of network address bytes.
  (declare (type stringable host)
           (type (or null (member :internet :decnet :chaos) card8) family))
  (declare (clx-values list))
  (ecase family
    ((:internet nil 0)
     (let* ((addr (ccl::host-as-inet-host host)))
       (cons :internet (list
                        (ldb (byte 8 24) addr)
                        (ldb (byte 8 16) addr)
                        (ldb (byte 8 8) addr)
                        (ldb (byte 8 0) addr)))))))

My apologies if this is the right place to raise this question -- there aren't many venues for discussion of these issues!

I'm using the StumpWM CL window manager, I believe with this version of CLX, and the Xorg package that comes with Archlinux, currently at 1.15.2-1.

My issue is that, after setting the keyboard layout to colemak using setxkbmap, it is reset to qwerty the first time I switch windows. It happens every time I switch windows, and there seems to be nothing I can do to keep it on colemak.

The StumpWM people don't know what's going on, and it seemed unlikely that the Xorg folks would think it was their issue. So here I am! I would appreciate any tips you all might be able to provide, including simply pointers to more likely locations of the difficulty.

I'm not sure that this is actually a CLX bug. Xquartz seems to use Unix sockets as the way to talk to the server. After I start up Xquartz, the DISPLAY variable has a value like: /private/tmp/com.apple.launchd.EauNyeZmg1/org.macosforge.xquartz:0
which CLX chokes on (it thinks that the empty string before the leading "/" is a protocol spec and gets horribly confused).

AFAICT this syntax for a DISPLAY spec isn't legal: it doesn't seem to agree with the X spec. But it's not like I have an alternate X server I can use....

Anyone able to use this CLX on Mac?

During work on a CLIM implementation I encountered the following problem with xlib: doing a PUT-IMAGE on an IMAGE-Z fails with a condition of: "The bits-per-pixel of the image #<XLIB:IMAGE-Z 12x12x24> does not match any server pixmap format.".

My current theory is that the error happens because, within the code of PUT-IMAGE, the pixmap-format found by depth (find depth (display-pixmap-formats display) :key #'pixmap-format-depth) is one with depth 24 and bpp of 32, and the latter is not equal to the expected 24 of (image-z-bits-per-pixel image).

There's a comment in PUT-IMAGE that seems relevant:

;; We could try to use the "/* XXX slow, but works */"
;; code in XPutImage from X11R4 here.  However, that
;; would require considerable support code
;; (see XImUtil.c, etc).

I wonder what exactly is the work needed here and how much effort would it take to make PUT-IMAGE work with this case.

Details

The issue was found on recent SBCL versions running on Ubuntu 16.04 (native) and on Ubuntu 14.04 (in VM), running both stock window manager and StumpWM.

Relevant object details:

• Call from condition backtrace:

(XLIB:PUT-IMAGE #<XLIB:PIXMAP :0 2600025> #<XLIB:GCONTEXT :0 39845924> #<XLIB:IMAGE-Z 12x12x24> :SRC-X 0 :SRC-Y 0 :X 0 :Y 0 :WIDTH NIL :HEIGHT NIL :BITMAP-P NIL)

• The IMAGE-Z object:

#<XLIB:IMAGE-Z {10082D1AD3}>
--------------------
The object is a STRUCTURE-OBJECT of type XLIB:IMAGE-Z.
WIDTH: 12
HEIGHT: 12
DEPTH: 24
PLIST: NIL
BITS-PER-PIXEL: 24
PIXARRAY: #2A((16777215 16777215 16777215 16777215 16777215 16777215 16777215 16777215 16777215 16777215 16777215 16777215) ..)

• The contents of the PIXMAP-FORMATS slot from the DISPLAY object referenced by PIXMAP object found in the stack trace:

A proper list:
0: #<XLIB:PIXMAP-FORMAT depth 1 bits-per-pixel 1 scanline-pad 32>
1: #<XLIB:PIXMAP-FORMAT depth 4 bits-per-pixel 8 scanline-pad 32>
2: #<XLIB:PIXMAP-FORMAT depth 8 bits-per-pixel 8 scanline-pad 32>
3: #<XLIB:PIXMAP-FORMAT depth 15 bits-per-pixel 16 scanline-pad 32>
4: #<XLIB:PIXMAP-FORMAT depth 16 bits-per-pixel 16 scanline-pad 32>
5: #<XLIB:PIXMAP-FORMAT depth 24 bits-per-pixel 32 scanline-pad 32>
6: #<XLIB:PIXMAP-FORMAT depth 32 bits-per-pixel 32 scanline-pad 32>

I might be able to provide a simple reproducible test case after 2017-07-10. In the meantime, see this for more context.