sharplispers / clx Goto Github PK
View Code? Open in Web Editor NEWa fork of crhodes' fork of danb's fork of the CLX library, an X11 client for Common Lisp
License: Other
a fork of crhodes' fork of danb's fork of the CLX library, an X11 client for Common Lisp
License: Other
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 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))))
This base64 encoded .XAuthority file breaks read-xauth-entry. It's the 4th entry that breaks it.
steps to reproduce:
AAAABKwRqm4AATAAEk1JVC1NQUdJQy1DT09LSUUtMQAQFQ9gIfF5tJYrNva+w5NQlAAGABD+
gAAAAAAAAAIkVP/+mgWLAAEwABJNSVQtTUFHSUMtQ09PS0lFLTEAEBUPYCHxebSWKzb2vsOT
UJQBAAAEYXJjaAABMAASTUlULU1BR0lDLUNPT0tJRS0xABAVD2Ah8Xm0lis29r7Dk1CUAPwA
AAAAABJNSVQtTUFHSUMtQ09PS0lFLTEAEIeK/9/M6kB1huLzpUT9JtsAAAAEfwAAAQABMQAS
TUlULU1BR0lDLUNPT0tJRS0xABC5ScGiDUUsDC5hGetC+chmAQAABGFyY2gAATEAEk1JVC1N
QUdJQy1DT09LSUUtMQAQuUnBog1FLAwuYRnrQvnIZgAAAAR/AAABAAEyABJNSVQtTUFHSUMt
Q09PS0lFLTEAEBEIvywuCk6cr1hC7BzdJecBAAAEYXJjaAABMgASTUlULU1BR0lDLUNPT0tJ
RS0xABARCL8sLgpOnK9YQuwc3SXn
(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))
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?
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
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?
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'
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 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.
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.
README has a lot of stuff about asdf-install that probably isn't all that relevant any more.
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?
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?
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?
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:
extension-event-key-p
is defined normally (i.e., with load time semantics) in input.lisp.extension-event-key-p
is forward referenced in the deftype
for event-key
in clx.lisp.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.
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)
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.
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.
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.
Steps to reproduce:
setxkbmap -layout us
(eval-when (:load-toplevel :compile-toplevel :execute)
(ql:quickload 'climacs))
(climacs:climacs)
setxkbmap -layout fr
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
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.
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:
(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)
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) ..)
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.
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.
(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* "*"))))
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?
Would you please add a :description to CLX's system definition?
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.
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
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:
render-add-glyph
and signal an error if it's too large (simple, but not general enough).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).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
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:
setxkbmap pl
ALT-RIGHT + s
should produceclx
keyboard input)climacs
This issue is related to McCLIM/McCLIM#35 .
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.
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;
}
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.
(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?
Thanks
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 `:'
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/.
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.
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)
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)
(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)
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.
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
:
define-keysym
functionkeysym->character
as 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
The link in README.md
points to https://sharplispers.github.io/clx/ for the manual, but that page doesn't exist.
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]
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)
.....
currently we include demo files in main distribution in demos module.
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)))))))
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.
These are guarded by a feature clx-ansi-common-lisp
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:
xorg-fonts-misc
(or arabic24.pcf.gz
font from the preferred source)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)
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:
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.