From andreaussi at yahoo.it Wed Oct 9 14:04:39 2019 From: andreaussi at yahoo.it (Andrea Lenarduzzi) Date: Wed, 9 Oct 2019 14:04:39 +0000 (UTC) Subject: Matrox M-series xorg 1.2 support References: <746817157.8656568.1570629879511.ref@mail.yahoo.com> Message-ID: <746817157.8656568.1570629879511@mail.yahoo.com> Hi, I'm working to usw Matrox M9138 on Xorg 1.2I've found only one script (ftp://ftp.matrox.com/pub/mga/archive/linux/2015/1.4.3/m9xdriver-x86_32-1.4.3-80847-20140908-build_98.run), but this script want only old xorg and old kernel. Can you help me to use this Graphics card on recent linux distro? Thank Uzzi -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajax at redhat.com Wed Oct 9 16:42:30 2019 From: ajax at redhat.com (Adam Jackson) Date: Wed, 09 Oct 2019 12:42:30 -0400 Subject: Matrox M-series xorg 1.2 support In-Reply-To: <746817157.8656568.1570629879511@mail.yahoo.com> References: <746817157.8656568.1570629879511.ref@mail.yahoo.com> <746817157.8656568.1570629879511@mail.yahoo.com> Message-ID: <36714c41e19736e48bb9ba513e6e01e6d7ca6a78.camel@redhat.com> On Wed, 2019-10-09 at 14:04 +0000, Andrea Lenarduzzi wrote: > Hi, I'm working to usw Matrox M9138 on Xorg 1.2 > I've found only one script ( > ftp://ftp.matrox.com/pub/mga/archive/linux/2015/1.4.3/m9xdriver-x86_32-1.4.3-80847-20140908-build_98.run > ), but this script want only old xorg and old kernel. > > Can you help me to use this Graphics card on recent linux distro? Unfortunately the vesa driver is the best you're going to get with that card with open-source drivers. If Matrox felt like releasing some documentation (or just, like, the source code) I suspect someone would find the time to write a real driver... - ajax From ajax at redhat.com Wed Oct 9 17:48:51 2019 From: ajax at redhat.com (Adam Jackson) Date: Wed, 09 Oct 2019 13:48:51 -0400 Subject: [ANNOUNCE] libX11 1.6.9 Message-ID: A collection of build and documentation fixes, one preparatory change for a new xorgproto release, and a fix for a deadlock bug in _XReply. Thanks to all who contributed. Adam Jackson (3): makekeys: Detach ourselves from X headers entirely xkb: Provide ourselves libX11 1.6.9 Dmitry Osipenko (1): Fix lockup in _XReply() caused by recursive synchronization Ross Burton (1): src/util/Makefile: explicitly reset LINK to not use libtool Thomas E. Dickey (6): the last commit overlooked some fake-quote pairs another fake-quote fix trim trailing whitespace from manpages split lines at sentence endings fix a substitution error from recent commit, e.g, "s/^\.EE/XDe/" improve some formatting Walter Harms (8): note that we can handle kbd==NULL remove in-text macros replace home grown .ZN with std, .B and .BR fix TBL format Replace home-grown .Ds .De macro with man page .EX/.EE macro remove all private macro defines get rid of ``fake quotes'' fix ``fake quotes'' in text git tag: libX11-1.6.9 https://xorg.freedesktop.org/archive/individual/lib/libX11-1.6.9.tar.bz2 MD5: 55adbfb6d4370ecac5e70598c4e7eed2 libX11-1.6.9.tar.bz2 SHA1: 62456536411f2540fbd4a3f59ed8af94967124c2 libX11-1.6.9.tar.bz2 SHA256: 9cc7e8d000d6193fa5af580d50d689380b8287052270f5bb26a5fb6b58b2bed1 libX11-1.6.9.tar.bz2 SHA512: fc18f0dc17ade1fc37402179f52e1f2b9c7b7d3a1a9590fea13046eb0c5193b4796289431cd99388eac01e8e59de77db45d2c9675d4f05ef8cf3ba6382c3dd31 libX11-1.6.9.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/lib/libX11-1.6.9.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/lib/libX11-1.6.9.tar.gz MD5: dfb07c4921d29aa2fd17acf152646769 libX11-1.6.9.tar.gz SHA1: 0409b7f98b9f454bf31d9d7ebee7ac89aed5bd54 libX11-1.6.9.tar.gz SHA256: b8c0930a9b25de15f3d773288cacd5e2f0a4158e194935615c52aeceafd1107b libX11-1.6.9.tar.gz SHA512: c79cf0924e920a2e8d2e9af45e73ed42b565dea79ac68d4c3889033738274694b29cedb62c057fec1aa7f7ad7dcf843334fccb43470bbae7922d42373c1c6045 libX11-1.6.9.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/lib/libX11-1.6.9.tar.gz.sig - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part URL: From softorchestra at yahoo.com Thu Oct 10 01:05:41 2019 From: softorchestra at yahoo.com (Software Orchestration) Date: Thu, 10 Oct 2019 01:05:41 +0000 (UTC) Subject: Input driver on 1.15.1 vs. 1.19.6 References: <2102067055.70485.1570669541742.ref@mail.yahoo.com> Message-ID: <2102067055.70485.1570669541742@mail.yahoo.com> Hi, I have a client that has a working serial input driver on Ubuntu 14.04, which is running the Xorg 1.15.1 server. I'm tasked with getting this to work on Ubuntu 18.04 which is running Xorg 1.19.6 In looking at the X.Org Server wiki page: https://en.wikipedia.org/wiki/X.Org_Server I see that 1.15.1 is not supported anymore, but 1.19.6 still is. My question is if anything would have changed for the input device driver specs between these versions that would effect a serial input device? This is a touch screen, but it interfaces through serial. The code uses xf86ReadSerial() and xf86WriteSerial(). Are there any examples using the latest Xorg server available? The code does compile so I'm guessing those functions are in the current interfaces, or are different ones available now? The sources go back pretty far on 14.04 and I see ifdefs for XFREE86_V3 and XFREE86_V4. As such I was looking for some example code that shows how to interface with the 1.19.6 server, which is current for Ubuntu 18.04. Any advice? Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.coopersmith at oracle.com Thu Oct 10 01:59:28 2019 From: alan.coopersmith at oracle.com (Alan Coopersmith) Date: Wed, 9 Oct 2019 18:59:28 -0700 Subject: Input driver on 1.15.1 vs. 1.19.6 In-Reply-To: <2102067055.70485.1570669541742@mail.yahoo.com> References: <2102067055.70485.1570669541742.ref@mail.yahoo.com> <2102067055.70485.1570669541742@mail.yahoo.com> Message-ID: <65a91af0-bbb5-3699-06b3-b920b358642e@oracle.com> On 10/9/19 6:05 PM, Software Orchestration wrote: > Hi, I have a client that has a working serial input driver on Ubuntu 14.04, > which is running the Xorg 1.15.1 server. > > I'm tasked with getting this to work on Ubuntu 18.04 which is running Xorg 1.19.6 > > In looking at the X.Org Server wiki page: > > https://en.wikipedia.org/wiki/X.Org_Server > > I see that 1.15.1 is not supported anymore, but 1.19.6 still is. I have no idea who decided what releases to list there as supported, but X.Org certainly isn't supporting all those releases upstream - though some downstream distros may be doing so. X.Org itself is mainly maintaining the 1.20 series now: https://gitlab.freedesktop.org/xorg/xserver/-/branches > My question is if anything would have changed for the input device driver specs > between these versions that would effect a serial input device? This is a touch > screen, but it interfaces through serial. There certainly have been driver API/ABI updates between the two: https://www.x.org/wiki/XorgModuleABIVersions/ > The code uses xf86ReadSerial() and xf86WriteSerial(). Doesn't look like there's been a whole lot of change there in recent years: https://gitlab.freedesktop.org/xorg/xserver/commits/master/hw/xfree86/os-support/shared/posix_tty.c > Are there any examples using the latest Xorg server available? Examples of input device drivers for Xorg? https://gitlab.freedesktop.org/xorg/driver?filter=input > The sources go back pretty far on 14.04 and I see ifdefs for XFREE86_V3 and > XFREE86_V4. XFREE86_V3 code is almost 20 years out of date now, while XFREE86_V4 code would be closer to 15 years out of date. -- -Alan Coopersmith- alan.coopersmith at oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc From softorchestra at yahoo.com Thu Oct 10 02:27:36 2019 From: softorchestra at yahoo.com (Software Orchestration) Date: Thu, 10 Oct 2019 02:27:36 +0000 (UTC) Subject: Input driver on 1.15.1 vs. 1.19.6 In-Reply-To: <65a91af0-bbb5-3699-06b3-b920b358642e@oracle.com> References: <2102067055.70485.1570669541742.ref@mail.yahoo.com> <2102067055.70485.1570669541742@mail.yahoo.com> <65a91af0-bbb5-3699-06b3-b920b358642e@oracle.com> Message-ID: <1244612343.150259.1570674456419@mail.yahoo.com> Alan Coopersmith wrote: > I have no idea who decided what releases to list there as supported, but X.Org > certainly isn't supporting all those releases upstream - though some downstream > distros may be doing so. X.Org itself is mainly maintaining the 1.20 series now: > https://gitlab.freedesktop.org/xorg/xserver/-/branches I figured you were on this list...thanks for replying. My question is first trying to understand what I need to get this working on Ubuntu 18.04. Currently the Xorg server is 1.19.6 and I don't see that changing until 20.04. They will still have 1 more year on 18.04 as it's a 5 year LTS I believe. First I'm just trying to understand if interfaces changed, if legacy works at all, or what the differences are so I can isolate the problem and fix it. If an input driver was brought up to 1.19.x, would it be likely to run on 1.20.x? I think I could get 1.20 on Ubuntu 19.08, do you know if that's the case? > There certainly have been driver API/ABI updates between the two: > https://www.x.org/wiki/XorgModuleABIVersions/ I saw in 1.16.x there was quite a bit of input changes, but wasn't sure how the APIs are supported. There seems to be a fairly large grey area. On top of all that, the was hacked together from another serial device, so as you might imagine it's a pretty big mess...but the good thing is there's only about 1000 LOC for the current driver. I'm trying to figure out if I might be better off starting off with a current serial input device as a template and merge their code to get a working driver on 18.04. > > The code uses xf86ReadSerial() and xf86WriteSerial(). > > Doesn't look like there's been a whole lot of change there in recent years: > https://gitlab.freedesktop.org/xorg/xserver/commits/master/hw/xfree86/os-support/shared/posix_tty.c That's good, maybe my chance is pretty good on 18.04. > Examples of input device drivers for Xorg? > > https://gitlab.freedesktop.org/xorg/driver?filter=input> ... > XFREE86_V3 code is almost 20 years out of date now, while XFREE86_V4 code would > be closer to 15 years out of date. Thanks for that link, looks like the xf86-input-libinput might be good for me to look at. I wish I wasn't doing this, but I really needed the work...so...I'd like to try and solve this for my client. Running on an old Atom processor that is at least 10+ years old, limited on memory, etc...I've seen this movie a number of times over the years...it's kind of like a rerun...:-/ Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From softorchestra at yahoo.com Thu Oct 10 02:31:12 2019 From: softorchestra at yahoo.com (Software Orchestration) Date: Thu, 10 Oct 2019 02:31:12 +0000 (UTC) Subject: Input driver on 1.15.1 vs. 1.19.6 In-Reply-To: <1244612343.150259.1570674456419@mail.yahoo.com> References: <2102067055.70485.1570669541742.ref@mail.yahoo.com> <2102067055.70485.1570669541742@mail.yahoo.com> <65a91af0-bbb5-3699-06b3-b920b358642e@oracle.com> <1244612343.150259.1570674456419@mail.yahoo.com> Message-ID: <216875656.118832.1570674672487@mail.yahoo.com> > I think I could get 1.20 on Ubuntu 19.08, do you know if that's the case? I should add, the client doesn't want to got to a non-LTS distribution. Doesn't sound like there's any compelling reason to go there, and hopefully the same code would run on 1.20 when the time comes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.hutterer at who-t.net Fri Oct 11 04:35:44 2019 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Fri, 11 Oct 2019 14:35:44 +1000 Subject: Input driver on 1.15.1 vs. 1.19.6 In-Reply-To: <1244612343.150259.1570674456419@mail.yahoo.com> References: <2102067055.70485.1570669541742.ref@mail.yahoo.com> <2102067055.70485.1570669541742@mail.yahoo.com> <65a91af0-bbb5-3699-06b3-b920b358642e@oracle.com> <1244612343.150259.1570674456419@mail.yahoo.com> Message-ID: <20191011043544.GA210767@jelly> On Thu, Oct 10, 2019 at 02:27:36AM +0000, Software Orchestration wrote: > > Alan Coopersmith wrote: > I have no idea who decided what releases to list there as supported, but X.Org > > certainly isn't supporting all those releases upstream - though some downstream > > distros may be doing so. X.Org itself is mainly maintaining the 1.20 series now: > > https://gitlab.freedesktop.org/xorg/xserver/-/branches > > I figured you were on this list...thanks for replying. > My question is first trying to understand what I need to get this working on Ubuntu 18.04. Currently the Xorg server is 1.19.6 and I don't see that changing until 20.04. They will still have 1 more year on 18.04 as it's a 5 year LTS I believe. > First I'm just trying to understand if interfaces changed, if legacy works at all, or what the differences are so I can isolate the problem and fix it. > If an input driver was brought up to 1.19.x, would it be likely to run on 1.20.x? > I think I could get 1.20 on Ubuntu 19.08, do you know if that's the case? I'd argue that any input driver that worked in the past should still work with current X servers, provided that you switch the SIGIO bits over to handle input threads instead. There are very few features that have truly been removed from input drivers such as access to the screen dimensions etc. Can't remember when this happen but my gut feeling is that if it worked on 1.15 it'll probably work on 1.19. Cheers, Peter > > There certainly have been driver API/ABI updates between the two: > > https://www.x.org/wiki/XorgModuleABIVersions/ > I saw in 1.16.x there was quite a bit of input changes, but wasn't sure how the APIs are supported. > There seems to be a fairly large grey area. > On top of all that, the was hacked together from another serial device, so as you might imagine it's a pretty big mess...but the good thing is there's only about 1000 LOC for the current driver. > I'm trying to figure out if I might be better off starting off with a current serial input device as a template and merge their code to get a working driver on 18.04. > > > > The code uses xf86ReadSerial() and xf86WriteSerial(). > > > > Doesn't look like there's been a whole lot of change there in recent years: > > https://gitlab.freedesktop.org/xorg/xserver/commits/master/hw/xfree86/os-support/shared/posix_tty.c > > That's good, maybe my chance is pretty good on 18.04. > > > Examples of input device drivers for Xorg? > > > > https://gitlab.freedesktop.org/xorg/driver?filter=input> ... > > XFREE86_V3 code is almost 20 years out of date now, while XFREE86_V4 code would > > be closer to 15 years out of date. > Thanks for that link, looks like the xf86-input-libinput might be good for me to look at. > I wish I wasn't doing this, but I really needed the work...so...I'd like to try and solve this for my client. Running on an old Atom processor that is at least 10+ years old, limited on memory, etc...I've seen this movie a number of times over the years...it's kind of like a rerun...:-/ > > Alan > > _______________________________________________ > xorg at 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 From nanuminj874 at gmail.com Thu Oct 10 19:41:47 2019 From: nanuminj874 at gmail.com (Nanu Minj) Date: Fri, 11 Oct 2019 01:11:47 +0530 Subject: intel i810 and XVi my. deo BLITTER/TEXTURE (NOT overlay) Message-ID: Xxxvideo -------------- next part -------------- An HTML attachment was scrubbed... URL: From softorchestra at yahoo.com Fri Oct 11 10:29:05 2019 From: softorchestra at yahoo.com (Software Orchestration) Date: Fri, 11 Oct 2019 10:29:05 +0000 (UTC) Subject: Input driver on 1.15.1 vs. 1.19.6 In-Reply-To: <20191011043544.GA210767@jelly> References: <2102067055.70485.1570669541742.ref@mail.yahoo.com> <2102067055.70485.1570669541742@mail.yahoo.com> <65a91af0-bbb5-3699-06b3-b920b358642e@oracle.com> <1244612343.150259.1570674456419@mail.yahoo.com> <20191011043544.GA210767@jelly> Message-ID: <558673137.863615.1570789745317@mail.yahoo.com> On Thursday, October 10, 2019, 9:35:47 PM PDT, Peter Hutterer wrote: > I'd argue that any input driver that worked in the past should still work > with current X servers, provided that you switch the SIGIO bits over to > handle input threads instead. > > There are very few features that have truly been removed from input drivers> such as access to the screen dimensions etc. Can't remember when this happen > but my gut feeling is that if it worked on 1.15 it'll probably work on > 1.19. Peter, Yes, I kind of was thinking that last night, or at least that this should actually work. AlanC pointed out that those functions haven't changed much. One thing I had to do in order to compile the code on Ubuntu 18.04 was add an include for as it was giving me a redefinition in one of the libraries called from xf86Xinput.h. If you could elaborate a tad I would appreciate it. In regard to what you mention with switching over to an input thread, will that let me register a callback that Xorg will send back for all the input events? And then I could just r/w the serial through the xf86 calls? Also, the old style with the SIGIO, it exported the init routine. I haven't dug into the code too much, other than getting it to compile. The old driver was 32-bit, and 32-bit is not supported on Ubuntu 18.04 moving forward. Old X, 32-bit, old hardware, etc...this is not a glamorous project. This weekend I'm going to try and decide, use what is there, or just write a new input module. This one is pretty ugly and there's a lot of #ifdefs for old versions. I am still not clear when Xorg 4.x switched over, possibly 2005 or so? Are these defines for XFREE86_V3 and XFREE86_V4 older than Xorg 4? Was that the old XFree86? I looked through those input drivers that AlanC pointed to and the synaptics uses the xf86ReadSerial() and xf86WriteSerial(). I just need a simple module that will stuff the touch to the mouse. I'm ok with re-writing, and my client is ok with that also (as long as it doesn't take too long), but I need to decide pretty quickly if that is the best way to approach this. The previous driver was morphed from the wacom driver. I would guess because it was as close to the serial driver they needed. So the code is ugly and creating a new input module could be worth it. Especially if this will take the client to 1.20, or if it will continue working for the client on Ubuntu 20.04. Although that is not a requirement for me, that would give them another 5 years from next April for 20.04 to end support. I'll look through those input drivers AlanC pointed to and see if I see an example using input threads. Thanks for your reply. Alan (and sorry this stupid yahoo mail sent HTML to the list, I changed that, I hope) -------------- next part -------------- An HTML attachment was scrubbed... URL: From softorchestra at yahoo.com Fri Oct 11 10:52:12 2019 From: softorchestra at yahoo.com (Software Orchestration) Date: Fri, 11 Oct 2019 10:52:12 +0000 (UTC) Subject: Input driver on 1.15.1 vs. 1.19.6 In-Reply-To: <20191011043544.GA210767@jelly> References: <2102067055.70485.1570669541742.ref@mail.yahoo.com> <2102067055.70485.1570669541742@mail.yahoo.com> <65a91af0-bbb5-3699-06b3-b920b358642e@oracle.com> <1244612343.150259.1570674456419@mail.yahoo.com> <20191011043544.GA210767@jelly> Message-ID: <223515686.854414.1570791132270@mail.yahoo.com> On Thursday, October 10, 2019, 9:35:47 PM PDT, Peter Hutterer wrote: > provided that you switch the SIGIO bits over to handle input threads instead. I see the eventcomm.c file in the synaptics driver: https://gitlab.freedesktop.org/xorg/driver/xf86-input-synaptics/blob/master/src/eventcomm.c And the ps2comm.c file could be similar to what I need. It read/writes serial to the PS/2 port. https://gitlab.freedesktop.org/xorg/driver/xf86-input-synaptics/blob/master/src/ps2comm.c I need to dig more, thanks for the direction. I need to make a decision tomorrow, but seems a new driver could be in order. Alan From michel at daenzer.net Fri Oct 11 16:46:13 2019 From: michel at daenzer.net (Michel =?ISO-8859-1?Q?D=E4nzer?=) Date: Fri, 11 Oct 2019 18:46:13 +0200 Subject: [ANNOUNCE] xf86-video-amdgpu 19.1.0 Message-ID: I'm pleased to announce the 19.1.0 release of xf86-video-amdgpu, the Xorg driver for AMD Radeon GPUs supported by the amdgpu kernel driver. This release supports xserver versions 1.13-1.20. There are no big changes in this release, just fixes and other minor improvements. Thanks to everybody who contributed to this release in any way! NOTE: As of September, I'm no longer working for AMD but for Red Hat's graphics infrastructure team. I'm hoping that someone from my former team at AMD will step up to maintain this driver. Flora Cui (1): dri2: reply to client for WaitMSC request in any case Michel Dänzer (13): Retry get_fb_ptr in get_fb dri3: Always flush glamor before sharing pixmap storage with clients dri2: Re-use previous CRTC when possible if pick_best_crtc returns NULL Remove dri2_drawable_crtc parameter consider_disabled present: Check that we can get a KMS FB for flipping Don't disable page flipping completely with SW cursor gitlab-ci: Use templates from wayland/ci-templates present: Also check pixmap pitch in check_flip with current xserver present: Don't check pixmap pitch in check_flip with current DC present: Don't check pixmap pitch in check_flip with non-DC >= 3.34 Don't set up black scanout buffer if LeaveVT is called from CloseScreen Don't unreference FBs of pixmaps from different screens in LeaveVT Bump version for the 19.1.0 release git tag: xf86-video-amdgpu-19.1.0 https://xorg.freedesktop.org/archive/individual/driver/xf86-video-amdgpu-19.1.0.tar.bz2 MD5: 55ad19b858e186a2cf4e91ed832c05e7 xf86-video-amdgpu-19.1.0.tar.bz2 SHA1: 044a97ea2f36dd3d2d4844bb503dd4e2b2854d56 xf86-video-amdgpu-19.1.0.tar.bz2 SHA256: 4f0ea4e0ae61995ac2b7c72433d31deab63b60c78763020aaa1b28696124fe5d xf86-video-amdgpu-19.1.0.tar.bz2 SHA512: ccdaa2378492da1a2f3d18fedacd1318c4708da534a8a959276a82730d5420619d83ad1ec8d7835c55655fe56123cd9bffb44e6223c5a97033c01f598af4a173 xf86-video-amdgpu-19.1.0.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-amdgpu-19.1.0.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/driver/xf86-video-amdgpu-19.1.0.tar.gz MD5: 5aec06fed52d09838d0511c59dd2d861 xf86-video-amdgpu-19.1.0.tar.gz SHA1: 453ef4c403c1966bb0555057248629a1514ab18e xf86-video-amdgpu-19.1.0.tar.gz SHA256: 9967435ca5686395375adea503ee774ddb95181505247d164ee3a1a2995a081f xf86-video-amdgpu-19.1.0.tar.gz SHA512: 660bea3ff6c8123ebc7df82b8e90308759c1575a3b28fddc95f0e46b575250991eda36f0e85d9db9777d712c247dadc8ce1f45541146ac513ec8874b774a440d xf86-video-amdgpu-19.1.0.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-amdgpu-19.1.0.tar.gz.sig -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 224 bytes Desc: This is a digitally signed message part URL: From michel at daenzer.net Fri Oct 11 16:46:13 2019 From: michel at daenzer.net (Michel =?ISO-8859-1?Q?D=E4nzer?=) Date: Fri, 11 Oct 2019 18:46:13 +0200 Subject: [ANNOUNCE] xf86-video-amdgpu 19.1.0 Message-ID: I'm pleased to announce the 19.1.0 release of xf86-video-amdgpu, the Xorg driver for AMD Radeon GPUs supported by the amdgpu kernel driver. This release supports xserver versions 1.13-1.20. There are no big changes in this release, just fixes and other minor improvements. Thanks to everybody who contributed to this release in any way! NOTE: As of September, I'm no longer working for AMD but for Red Hat's graphics infrastructure team. I'm hoping that someone from my former team at AMD will step up to maintain this driver. Flora Cui (1): dri2: reply to client for WaitMSC request in any case Michel Dänzer (13): Retry get_fb_ptr in get_fb dri3: Always flush glamor before sharing pixmap storage with clients dri2: Re-use previous CRTC when possible if pick_best_crtc returns NULL Remove dri2_drawable_crtc parameter consider_disabled present: Check that we can get a KMS FB for flipping Don't disable page flipping completely with SW cursor gitlab-ci: Use templates from wayland/ci-templates present: Also check pixmap pitch in check_flip with current xserver present: Don't check pixmap pitch in check_flip with current DC present: Don't check pixmap pitch in check_flip with non-DC >= 3.34 Don't set up black scanout buffer if LeaveVT is called from CloseScreen Don't unreference FBs of pixmaps from different screens in LeaveVT Bump version for the 19.1.0 release git tag: xf86-video-amdgpu-19.1.0 https://xorg.freedesktop.org/archive/individual/driver/xf86-video-amdgpu-19.1.0.tar.bz2 MD5: 55ad19b858e186a2cf4e91ed832c05e7 xf86-video-amdgpu-19.1.0.tar.bz2 SHA1: 044a97ea2f36dd3d2d4844bb503dd4e2b2854d56 xf86-video-amdgpu-19.1.0.tar.bz2 SHA256: 4f0ea4e0ae61995ac2b7c72433d31deab63b60c78763020aaa1b28696124fe5d xf86-video-amdgpu-19.1.0.tar.bz2 SHA512: ccdaa2378492da1a2f3d18fedacd1318c4708da534a8a959276a82730d5420619d83ad1ec8d7835c55655fe56123cd9bffb44e6223c5a97033c01f598af4a173 xf86-video-amdgpu-19.1.0.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-amdgpu-19.1.0.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/driver/xf86-video-amdgpu-19.1.0.tar.gz MD5: 5aec06fed52d09838d0511c59dd2d861 xf86-video-amdgpu-19.1.0.tar.gz SHA1: 453ef4c403c1966bb0555057248629a1514ab18e xf86-video-amdgpu-19.1.0.tar.gz SHA256: 9967435ca5686395375adea503ee774ddb95181505247d164ee3a1a2995a081f xf86-video-amdgpu-19.1.0.tar.gz SHA512: 660bea3ff6c8123ebc7df82b8e90308759c1575a3b28fddc95f0e46b575250991eda36f0e85d9db9777d712c247dadc8ce1f45541146ac513ec8874b774a440d xf86-video-amdgpu-19.1.0.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-amdgpu-19.1.0.tar.gz.sig -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 224 bytes Desc: This is a digitally signed message part URL: From softorchestra at yahoo.com Fri Oct 11 18:34:25 2019 From: softorchestra at yahoo.com (Software Orchestration) Date: Fri, 11 Oct 2019 18:34:25 +0000 (UTC) Subject: Input driver on 1.15.1 vs. 1.19.6 In-Reply-To: <20191011043544.GA210767@jelly> References: <2102067055.70485.1570669541742.ref@mail.yahoo.com> <2102067055.70485.1570669541742@mail.yahoo.com> <65a91af0-bbb5-3699-06b3-b920b358642e@oracle.com> <1244612343.150259.1570674456419@mail.yahoo.com> <20191011043544.GA210767@jelly> Message-ID: <1114851249.1115013.1570818865983@mail.yahoo.com> On Thursday, October 10, 2019, 9:35:57 PM PDT, Peter Hutterer wrote: > provided that you switch the SIGIO bits over to handle input threads instead. I saw this page on the Xorg site: https://www.x.org/wiki/Development/Documentation/XorgInputHOWTO/ But if I'm not mistaken, from what Peter was saying this would be the old style and not the input threaded version, correct? Seems like they're using  I believe what Peter was suggesting is to replace the SIGIO with the following? https://www.x.org/wiki/Development/Documentation/InputEventProcessing/ Seems like there's a lot of old documentation on the Xorg site also. I'm trying to decide where a good point to start is, whether I start trimming down and use the synaptic driver, or create a new skeleton. There's a lot of stuff I don't need in the synaptics, so if I go that route I will try to remove the un-needed stuff. Any comments? Alan From peter.hutterer at who-t.net Fri Oct 11 22:33:44 2019 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Sat, 12 Oct 2019 08:33:44 +1000 Subject: Input driver on 1.15.1 vs. 1.19.6 In-Reply-To: <558673137.863615.1570789745317@mail.yahoo.com> References: <2102067055.70485.1570669541742.ref@mail.yahoo.com> <2102067055.70485.1570669541742@mail.yahoo.com> <65a91af0-bbb5-3699-06b3-b920b358642e@oracle.com> <1244612343.150259.1570674456419@mail.yahoo.com> <20191011043544.GA210767@jelly> <558673137.863615.1570789745317@mail.yahoo.com> Message-ID: On 11/10/19 20:29 , Software Orchestration wrote: > On Thursday, October 10, 2019, 9:35:47 PM PDT, Peter Hutterer wrote: > I'd argue that any input driver that worked in the past should still work >> with current X servers, provided that you switch the SIGIO bits over to >> handle input threads instead. >> >> There are very few features that have truly been removed from input drivers> such as access to the screen dimensions etc. Can't remember when this happen >> but my gut feeling is that if it worked on 1.15 it'll probably work on >> 1.19. > > Peter, > > Yes, I kind of was thinking that last night, or at least that this should actually work. AlanC pointed out that those functions haven't changed much. One thing I had to do in order to compile the code on Ubuntu 18.04 was add an include for as it was giving me a redefinition in one of the libraries called from xf86Xinput.h. If you could elaborate a tad I would appreciate it. the headers may have shuffled things around a bit - without knowing your source code I can't really comment on what has changed for you. but I don't expect there to be anything that's not resolved by including some standard headers. > In regard to what you mention with switching over to an input thread, will that let me register a callback that Xorg will send back for all the input events? And then I could just r/w the serial through the xf86 calls? drivers register a file descriptor that is added to the server's internal poll() call. When data is available, your callback is invoked and you can process data. For the most part you don't really need to care about the input thread within the driver, it's largely handled by the server anyway. > Also, the old style with the SIGIO, it exported the init routine. I haven't dug into the code too much, other than getting it to compile. The old driver was 32-bit, and 32-bit is not supported on Ubuntu 18.04 moving forward. Old X, 32-bit, old hardware, etc...this is not a glamorous project. > > This weekend I'm going to try and decide, use what is there, or just write a new input module. This one is pretty ugly and there's a lot of #ifdefs for old versions. I am still not clear when Xorg 4.x switched over, possibly 2005 or so? Are these defines for XFREE86_V3 and XFREE86_V4 older than Xorg 4? Was that the old XFree86? yeah, you don't need any of those for newer servers. > I looked through those input drivers that AlanC pointed to and the synaptics uses the xf86ReadSerial() and xf86WriteSerial(). I just need a simple module that will stuff the touch to the mouse. > > I'm ok with re-writing, and my client is ok with that also (as long as it doesn't take too long), but I need to decide pretty quickly if that is the best way to approach this. > The previous driver was morphed from the wacom driver. I would guess because it was as close to the serial driver they needed. So the code is ugly and creating a new input module could be worth it. Especially if this will take the client to 1.20, or if it will continue working for the client on Ubuntu 20.04. Although that is not a requirement for me, that would give them another 5 years from next April for 20.04 to end support. > > I'll look through those input drivers AlanC pointed to and see if I see an example using input threads. look at early versions of the xf86-input-libinput driver. that's the most modern code base and an early-enough version doesn't have the fancy bits the current driver has to split into subdevices etc. You can probably take that code and replace the read callback with your device-specific data and you're good to go. -ish :) There's no documentation that's up to date, writing xorg input drivers simply isn't a thing anymore and the one person who still does that on a regular basis already know how it works ;) Cheers, Peter > Thanks for your reply. > Alan (and sorry this stupid yahoo mail sent HTML to the list, I changed that, I hope) > > From softorchestra at yahoo.com Sat Oct 12 00:43:29 2019 From: softorchestra at yahoo.com (Software Orchestration) Date: Sat, 12 Oct 2019 00:43:29 +0000 (UTC) Subject: Input driver on 1.15.1 vs. 1.19.6 In-Reply-To: References: <2102067055.70485.1570669541742.ref@mail.yahoo.com> <2102067055.70485.1570669541742@mail.yahoo.com> <65a91af0-bbb5-3699-06b3-b920b358642e@oracle.com> <1244612343.150259.1570674456419@mail.yahoo.com> <20191011043544.GA210767@jelly> <558673137.863615.1570789745317@mail.yahoo.com> Message-ID: <1005256699.1245339.1570841009702@mail.yahoo.com> On Friday, October 11, 2019, 3:33:52 PM PDT, Peter Hutterer wrote: > the headers may have shuffled things around a bit - without knowing your > source code I can't really comment on what has changed for you. but I > don't expect there to be anything that's not resolved by including some > standard headers. It might work by working on the code, I do get a valid shared library that seems to load, but it is pretty ugly how it is and will take some time to get it working, IMO. I'm not clear on how much exactly, but it would be better to create a new one. This is a point of sale devices, and really doesn't need to do too much. AFAIK, all the other devices are USB touchscreens. This one is a serial. > drivers register a file descriptor that is added to the server's > internal poll() call. When data is available, your callback is invoked > and you can process data. For the most part you don't really need to > care about the input thread within the driver, it's largely handled by > the server anyway. That answers about the polling, I didn't think I needed to do that like a USB driver. I've abandoned using the synaptics driver, it doesn't do too much for me other than call the serial. I think I've narrowed a start to: xf86-input-void - https://gitlab.freedesktop.org/xorg/driver/xf86-input-void or xf86-input-evdev -  https://gitlab.freedesktop.org/xorg/driver/xf86-input-evdev I do have my device listed in /proc/bus/devices and it points me to the event, and I checked and see the kernel has the needed CONFIG_INPUT_EVDEV, and that would make me lean towards the xf86-input-evdev sources as a start, which I think they were intended to be. > and an early-enough version doesn't have the fancy > bits the current driver has to split into subdevices etc. When you say subdevices, in the evdev it has a middle button, third button, wheel, etc...is that what you're saying to avoid? Or are you talking about a keyboard, mouse, touchscreen type driver? (if such exists, I think it does) Thanks for your help. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.hutterer at who-t.net Sat Oct 12 02:38:51 2019 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Sat, 12 Oct 2019 12:38:51 +1000 Subject: Input driver on 1.15.1 vs. 1.19.6 In-Reply-To: <1005256699.1245339.1570841009702@mail.yahoo.com> References: <2102067055.70485.1570669541742.ref@mail.yahoo.com> <2102067055.70485.1570669541742@mail.yahoo.com> <65a91af0-bbb5-3699-06b3-b920b358642e@oracle.com> <1244612343.150259.1570674456419@mail.yahoo.com> <20191011043544.GA210767@jelly> <558673137.863615.1570789745317@mail.yahoo.com> <1005256699.1245339.1570841009702@mail.yahoo.com> Message-ID: <91f96da8-0133-6a9c-dd32-baf434e51dc8@who-t.net> On 12/10/19 10:43 , Software Orchestration wrote: > On Friday, October 11, 2019, 3:33:52 PM PDT, Peter Hutterer wrote: >> the headers may have shuffled things around a bit - without knowing your >> source code I can't really comment on what has changed for you. but I >> don't expect there to be anything that's not resolved by including some >> standard headers. > > It might work by working on the code, I do get a valid shared library that seems to load, but it is pretty ugly how it is and will take some time to get it working, IMO. I'm not clear on how much exactly, but it would be better to create a new one. This is a point of sale devices, and really doesn't need to do too much. AFAIK, all the other devices are USB touchscreens. This one is a serial. > >> drivers register a file descriptor that is added to the server's >> internal poll() call. When data is available, your callback is invoked >> and you can process data. For the most part you don't really need to >> care about the input thread within the driver, it's largely handled by >> the server anyway. > > That answers about the polling, I didn't think I needed to do that like a USB driver. > > I've abandoned using the synaptics driver, it doesn't do too much for me other than call the serial. I think I've narrowed a start to: > > xf86-input-void - https://gitlab.freedesktop.org/xorg/driver/xf86-input-void > > or > > xf86-input-evdev -  https://gitlab.freedesktop.org/xorg/driver/xf86-input-evdev > > I do have my device listed in /proc/bus/devices and it points me to the event, and I checked and see the kernel has the needed CONFIG_INPUT_EVDEV, and that would make me lean towards the xf86-input-evdev sources as a start, which I think they were intended to be. if your device has a /dev/input/eventX node anyway, then yes, evdev is the way to go. You may not need any modification at all, evdev may do the trick. >> and an early-enough version doesn't have the fancy >> bits the current driver has to split into subdevices etc. > > When you say subdevices, in the evdev it has a middle button, third button, wheel, etc...is that what you're saying to avoid? Or are you talking about a keyboard, mouse, touchscreen type driver? (if such exists, I think it does) the X server isn't great at handling devices that are both mouse and keyboard, so we end up splitting those evdev devices into two X devices, one for the keyboard events and one for the pointer events. That's what the "subdevices" term refers to in the libinput driver. For a device that's a touchscreen only you don't need to care about that. Cheers, Peter > Thanks for your help. > Alan > From softorchestra at yahoo.com Sat Oct 12 03:19:52 2019 From: softorchestra at yahoo.com (Software Orchestration) Date: Sat, 12 Oct 2019 03:19:52 +0000 (UTC) Subject: Input driver on 1.15.1 vs. 1.19.6 In-Reply-To: <91f96da8-0133-6a9c-dd32-baf434e51dc8@who-t.net> References: <2102067055.70485.1570669541742.ref@mail.yahoo.com> <2102067055.70485.1570669541742@mail.yahoo.com> <65a91af0-bbb5-3699-06b3-b920b358642e@oracle.com> <1244612343.150259.1570674456419@mail.yahoo.com> <20191011043544.GA210767@jelly> <558673137.863615.1570789745317@mail.yahoo.com> <1005256699.1245339.1570841009702@mail.yahoo.com> <91f96da8-0133-6a9c-dd32-baf434e51dc8@who-t.net> Message-ID: <1143945697.1265108.1570850392818@mail.yahoo.com> On Friday, October 11, 2019, 7:38:57 PM PDT, Peter Hutterer wrote: > if your device has a /dev/input/eventX node anyway, then yes, evdev is > the way to go. You may  not need any modification at all, evdev may do > the trick. I think I'm starting to understand how all of this starts up, the XF86ModuleData has the entry to call for the driver. Then the PreInit name is located in the InputDriverRec  which is passed with xf86AddInputDriver, that in turn triggers the PreInit which then receives the InputInfoPtr which a few things are assigned to, one being the main Proc that xorg will send events (pInfo->device_control). That InputInfo struct is used to open the device with EvdevOpenDevice. Some other stuff is done in the PreInit, but after that, I'm guessing that all the interaction between the driver and xorg is done through that Proc. Does that sounds correct? Thanks so much, I am starting to modify the evdev code. And just to be clear, I'm not really re-writing the driver, I'm just taking what's there and putting it inside this new framework. The client will thank me in the end, unless I fall on my face...LOL From peter.hutterer at who-t.net Sun Oct 13 21:54:34 2019 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Mon, 14 Oct 2019 07:54:34 +1000 Subject: Input driver on 1.15.1 vs. 1.19.6 In-Reply-To: <1143945697.1265108.1570850392818@mail.yahoo.com> References: <2102067055.70485.1570669541742.ref@mail.yahoo.com> <2102067055.70485.1570669541742@mail.yahoo.com> <65a91af0-bbb5-3699-06b3-b920b358642e@oracle.com> <1244612343.150259.1570674456419@mail.yahoo.com> <20191011043544.GA210767@jelly> <558673137.863615.1570789745317@mail.yahoo.com> <1005256699.1245339.1570841009702@mail.yahoo.com> <91f96da8-0133-6a9c-dd32-baf434e51dc8@who-t.net> <1143945697.1265108.1570850392818@mail.yahoo.com> Message-ID: <20191013215434.GA267576@jelly> On Sat, Oct 12, 2019 at 03:19:52AM +0000, Software Orchestration wrote: > On Friday, October 11, 2019, 7:38:57 PM PDT, Peter Hutterer wrote: > > if your device has a /dev/input/eventX node anyway, then yes, evdev is > > the way to go. You may  not need any modification at all, evdev may do > > the trick. > > I think I'm starting to understand how all of this starts up, the > XF86ModuleData has the entry to call for the driver. Then the PreInit name > is located in the InputDriverRec  which is passed with xf86AddInputDriver, > that in turn triggers the PreInit which then receives the InputInfoPtr > which a few things are assigned to, one being the main Proc that xorg will > send events (pInfo->device_control). That InputInfo struct is used to open > the device with EvdevOpenDevice. Some other stuff is done in the PreInit, > but after that, I'm guessing that all the interaction between the driver > and xorg is done through that Proc. > > Does that sounds correct? yes, that's correct. Of note: DEVICE_INIT and DEVICE_CLOSE are only called once, but DEVICE_ON/OFF are called every time the device is enabled/disabled. That happens on vt swtich, suspend or on user request. xf86AddEnabledDevice() is the important bit in DEVICE_ON, it registers the fd with the server's poll(). read_input is the callback invoked on data and notably: that one is called from the input thread, not the main thread. Cheers, Peter > > Thanks so much, I am starting to modify the evdev code. And just to be > clear, I'm not really re-writing the driver, I'm just taking what's there > and putting it inside this new framework. The client will thank me in the > end, unless I fall on my face...LOL From michel at daenzer.net Tue Oct 15 16:27:28 2019 From: michel at daenzer.net (Michel =?ISO-8859-1?Q?D=E4nzer?=) Date: Tue, 15 Oct 2019 18:27:28 +0200 Subject: [ANNOUNCE] xf86-video-ati 19.1.0 Message-ID: <5c54232e90a83412e4ba5777b73716050d939def.camel@daenzer.net> I'm pleased to announce the 19.1.0 release of xf86-video-ati, the Xorg driver for ATI/AMD Radeon GPUs supported by the radeon kernel driver. This release supports xserver versions 1.13-1.20. There are no big changes in this release, just fixes and other minor improvements. Thanks to everybody who contributed to this release in any way! NOTE: As of September, I'm no longer working for AMD but for Red Hat's graphics/input infrastructure team. I'm hoping that someone from my former team at AMD will step up to maintain this driver. Flora Cui (1): dri2: reply to client for WaitMSC request in any case Michel Dänzer (9): Retry get_fb_ptr in get_fb dri3: Always flush glamor before sharing pixmap storage with clients dri2: Re-use previous CRTC when possible if pick_best_crtc returns NULL Remove dri2_drawable_crtc parameter consider_disabled present: Check that we can get a KMS FB for flipping Don't disable page flipping completely with SW cursor Don't set up black scanout buffer if LeaveVT is called from CloseScreen Don't unreference FBs of pixmaps from different screens in LeaveVT Bump version for 19.1.0 release git tag: xf86-video-ati-19.1.0 https://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-19.1.0.tar.bz2 MD5: 6e49d3c2839582af415ceded76e626e6 xf86-video-ati-19.1.0.tar.bz2 SHA1: aea1d11c05531b03f2eb67c6785cddf6d7f30e5f xf86-video-ati-19.1.0.tar.bz2 SHA256: 659f5a1629eea5f5334d9b39b18e6807a63aa1efa33c1236d9cc53acbb223c49 xf86-video-ati-19.1.0.tar.bz2 SHA512: 73a81f6c492daf2e89067fb52b3033dc0fe6841f109627ddca1aee54a45a738c8c134443753a2a2aaa2c131e1d560057ebc76351ff2304c16407df3ff568fcd6 xf86-video-ati-19.1.0.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-19.1.0.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-19.1.0.tar.gz MD5: c4172d2b6883a6e8e57c737248b3c9c8 xf86-video-ati-19.1.0.tar.gz SHA1: 6c5c06555c2aed695b28b5b5d617a994e9926410 xf86-video-ati-19.1.0.tar.gz SHA256: c05c6e0c396a0148113f1836cfab7f2e43f784c9b7041f11e9cab40a4bc0c90f xf86-video-ati-19.1.0.tar.gz SHA512: c382c68ed5f3a690b293e3b56dfdf71f5b279f52da6db925cb5302e595003f69451670fe1ec9546ad4d91cb328b367777f547757a69d70ed8b4ade75e613e302 xf86-video-ati-19.1.0.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-19.1.0.tar.gz.sig -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 224 bytes Desc: This is a digitally signed message part URL: From seba.kerckhof at gmail.com Tue Oct 15 14:34:31 2019 From: seba.kerckhof at gmail.com (Seba Kerckhof) Date: Tue, 15 Oct 2019 16:34:31 +0200 Subject: Using Intel GPU "TearFree" option changes my detected screens / edid information Message-ID: I was experiencing tearing on my Debian system. I read about the intel driver "TearFree" option and configured it as explained here: https://wiki.archlinux.org/index.php/Intel_graphics#Tearing While it does seem to help with the tearing, it changes my detected screens. By this I mean if I run xrandr, my display ports have a different name and the detected screens have a different EDID (model/vendor), different resolutions etc. This is the xrandr output without the intel configuration file: ``` Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384 DVI-I-0 disconnected primary (normal left inverted right x axis y axis) Identifier: 0x2de Timestamp: 113294 Subpixel: unknown Clones: CRTCs: 0 1 2 3 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: CscMatrix: 65536 0 0 0 0 65536 0 0 0 0 65536 0 BorderDimensions: 4 supported: 4 Border: 0 0 0 0 range: (0, 65535) SignalFormat: VGA supported: VGA ConnectorType: DVI-I ConnectorNumber: 0 _ConnectorLocation: 0 DVI-I-1 disconnected (normal left inverted right x axis y axis) Identifier: 0x2df Timestamp: 113294 Subpixel: unknown Clones: CRTCs: 0 1 2 3 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: CscMatrix: 65536 0 0 0 0 65536 0 0 0 0 65536 0 BorderDimensions: 4 supported: 4 Border: 0 0 0 0 range: (0, 65535) SignalFormat: TMDS supported: TMDS ConnectorType: DVI-I ConnectorNumber: 0 _ConnectorLocation: 0 DP-0 disconnected (normal left inverted right x axis y axis) Identifier: 0x2e0 Timestamp: 113294 Subpixel: unknown Clones: CRTCs: 0 1 2 3 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: CscMatrix: 65536 0 0 0 0 65536 0 0 0 0 65536 0 BorderDimensions: 4 supported: 4 Border: 0 0 0 0 range: (0, 65535) SignalFormat: TMDS supported: TMDS ConnectorType: DisplayPort ConnectorNumber: 2 _ConnectorLocation: 2 DP-1 connected 1920x1080+0+0 (0x2f4) normal (normal left inverted right x axis y axis) 0mm x 0mm Identifier: 0x2e1 Timestamp: 113294 Subpixel: unknown Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: CRTC: 0 CRTCs: 0 1 2 3 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: EDID: 00ffffffffffff004249696301000000 08190103800000780acf74a3574cb023 09484c21080081804540614095000101 010101010101023a801871382d40582c 4500c48e2100001e662150b051001b30 40703600c48e2100001e000000fc004c 45442d4d4f4e49544f520a20000000fd 00324b1e5017000a20202020202001a9 02032cf24d010304050790121314169f 202226090707111750830100006e030c 001000b844200080010203048c0ad08a 20e02d10103e9600c48e210000188c0a d090204031200c405500c48e21000018 011d00bc52d01e20b8285540c48e2100 001e011d80d0721c1620102c2580c48e 2100009e00000000000000000000007d CscMatrix: 65536 0 0 0 0 65536 0 0 0 0 65536 0 BorderDimensions: 4 supported: 4 Border: 0 0 0 0 range: (0, 65535) SignalFormat: TMDS supported: TMDS ConnectorType: DisplayPort ConnectorNumber: 1 _ConnectorLocation: 1 1920x1080 (0x2f4) 148.500MHz +HSync +VSync *current +preferred h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 67.50KHz v: height 1080 start 1084 end 1089 total 1125 clock 60.00Hz 1920x1080 (0x2f5) 148.350MHz +HSync +VSync h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 67.43KHz v: height 1080 start 1084 end 1089 total 1125 clock 59.94Hz 1920x1080 (0x2f6) 148.500MHz +HSync +VSync h: width 1920 start 2448 end 2492 total 2640 skew 0 clock 56.25KHz v: height 1080 start 1084 end 1089 total 1125 clock 50.00Hz 1920x1080 (0x2f7) 74.180MHz +HSync +VSync h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 33.72KHz v: height 1080 start 1084 end 1089 total 1125 clock 29.97Hz 1920x1080 (0x2f8) 74.160MHz +HSync +VSync h: width 1920 start 2558 end 2602 total 2750 skew 0 clock 26.97KHz v: height 1080 start 1084 end 1089 total 1125 clock 23.97Hz 1920x1080 (0x2f9) 74.180MHz +HSync +VSync Interlace h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 33.72KHz v: height 1080 start 1084 end 1094 total 1124 clock 60.00Hz 1920x1080 (0x2fa) 74.250MHz +HSync +VSync Interlace h: width 1920 start 2448 end 2492 total 2640 skew 0 clock 28.12KHz v: height 1080 start 1084 end 1094 total 1124 clock 50.04Hz 1440x900 (0x2fb) 106.500MHz -HSync +VSync h: width 1440 start 1520 end 1672 total 1904 skew 0 clock 55.93KHz v: height 900 start 903 end 909 total 934 clock 59.89Hz 1360x768 (0x2fc) 85.500MHz +HSync +VSync h: width 1360 start 1424 end 1536 total 1792 skew 0 clock 47.71KHz v: height 768 start 771 end 777 total 795 clock 60.02Hz 1280x1024 (0x2fd) 108.000MHz +HSync +VSync h: width 1280 start 1328 end 1440 total 1688 skew 0 clock 63.98KHz v: height 1024 start 1025 end 1028 total 1066 clock 60.02Hz 1280x720 (0x2fe) 74.180MHz +HSync +VSync h: width 1280 start 1390 end 1430 total 1650 skew 0 clock 44.96KHz v: height 720 start 725 end 730 total 750 clock 59.94Hz 1280x720 (0x2ff) 74.250MHz +HSync +VSync h: width 1280 start 1720 end 1760 total 1980 skew 0 clock 37.50KHz v: height 720 start 725 end 730 total 750 clock 50.00Hz 1024x768 (0x300) 65.000MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.36KHz v: height 768 start 771 end 777 total 806 clock 60.00Hz 800x600 (0x301) 40.000MHz +HSync +VSync h: width 800 start 840 end 968 total 1056 skew 0 clock 37.88KHz v: height 600 start 601 end 605 total 628 clock 60.32Hz 720x576 (0x302) 27.000MHz -HSync -VSync h: width 720 start 732 end 796 total 864 skew 0 clock 31.25KHz v: height 576 start 581 end 586 total 625 clock 50.00Hz 720x480 (0x303) 27.000MHz -HSync -VSync h: width 720 start 736 end 798 total 858 skew 0 clock 31.47KHz v: height 480 start 489 end 495 total 525 clock 59.94Hz 640x480 (0x304) 25.175MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew 0 clock 31.47KHz v: height 480 start 490 end 492 total 525 clock 59.94Hz 640x480 (0x305) 25.170MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew 0 clock 31.46KHz v: height 480 start 490 end 492 total 525 clock 59.93Hz DP-2 disconnected (normal left inverted right x axis y axis) Identifier: 0x2e2 Timestamp: 113294 Subpixel: unknown Clones: CRTCs: 0 1 2 3 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: CscMatrix: 65536 0 0 0 0 65536 0 0 0 0 65536 0 BorderDimensions: 4 supported: 4 Border: 0 0 0 0 range: (0, 65535) SignalFormat: DisplayPort supported: DisplayPort ConnectorType: DisplayPort ConnectorNumber: 2 _ConnectorLocation: 2 DP-3 disconnected (normal left inverted right x axis y axis) Identifier: 0x2e3 Timestamp: 113294 Subpixel: unknown Clones: CRTCs: 0 1 2 3 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: CscMatrix: 65536 0 0 0 0 65536 0 0 0 0 65536 0 BorderDimensions: 4 supported: 4 Border: 0 0 0 0 range: (0, 65535) SignalFormat: DisplayPort supported: DisplayPort ConnectorType: DisplayPort ConnectorNumber: 1 _ConnectorLocation: 1 ``` This is the xrandr output with the intel configuration file: ``` Screen 0: minimum 8 x 8, current 1920 x 1200, maximum 32767 x 32767 DP1 disconnected primary (normal left inverted right x axis y axis) Identifier: 0x43 Timestamp: 14646 Subpixel: unknown Clones: CRTCs: 0 1 2 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: Broadcast RGB: Automatic supported: Automatic, Full, Limited 16:235 audio: auto supported: force-dvi, off, auto, on DP2 disconnected (normal left inverted right x axis y axis) Identifier: 0x44 Timestamp: 14646 Subpixel: unknown Clones: CRTCs: 0 1 2 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: Broadcast RGB: Automatic supported: Automatic, Full, Limited 16:235 audio: auto supported: force-dvi, off, auto, on DP3 connected 1920x1200+0+0 (0x4c) normal (normal left inverted right x axis y axis) 0mm x 0mm Identifier: 0x45 Timestamp: 14646 Subpixel: unknown Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: CRTC: 0 CRTCs: 0 1 2 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: EDID: 00ffffffffffff000d12117570030000 15150104a5000078e28042ac5130b425 10505300000001010101010101010101 010101010101283c80a070b023403020 360007442100001a213280a070b02340 3020360007442100001a000000fd0038 4c1e5311000a202020202020000000fc 00434837353131420a20202020200012 Broadcast RGB: Automatic supported: Automatic, Full, Limited 16:235 audio: auto supported: force-dvi, off, auto, on 1920x1200 (0x4c) 154.000MHz +HSync -VSync *current +preferred h: width 1920 start 1968 end 2000 total 2080 skew 0 clock 74.04KHz v: height 1200 start 1203 end 1209 total 1235 clock 59.95Hz 1920x1200 (0x83) 128.330MHz +HSync -VSync h: width 1920 start 1968 end 2000 total 2080 skew 0 clock 61.70KHz v: height 1200 start 1203 end 1209 total 1235 clock 49.96Hz HDMI1 disconnected (normal left inverted right x axis y axis) Identifier: 0x46 Timestamp: 14646 Subpixel: unknown Clones: VGA1 CRTCs: 0 1 2 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: aspect ratio: Automatic supported: Automatic, 4:3, 16:9 Broadcast RGB: Automatic supported: Automatic, Full, Limited 16:235 audio: auto supported: force-dvi, off, auto, on HDMI2 disconnected (normal left inverted right x axis y axis) Identifier: 0x47 Timestamp: 14646 Subpixel: unknown Clones: VGA1 CRTCs: 0 1 2 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: aspect ratio: Automatic supported: Automatic, 4:3, 16:9 Broadcast RGB: Automatic supported: Automatic, Full, Limited 16:235 audio: auto supported: force-dvi, off, auto, on HDMI3 disconnected (normal left inverted right x axis y axis) Identifier: 0x48 Timestamp: 14646 Subpixel: unknown Clones: VGA1 CRTCs: 0 1 2 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: aspect ratio: Automatic supported: Automatic, 4:3, 16:9 Broadcast RGB: Automatic supported: Automatic, Full, Limited 16:235 audio: auto supported: force-dvi, off, auto, on VGA1 disconnected (normal left inverted right x axis y axis) Identifier: 0x49 Timestamp: 14646 Subpixel: unknown Clones: HDMI1 HDMI2 HDMI3 CRTCs: 0 1 2 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: VIRTUAL1 disconnected (normal left inverted right x axis y axis) Identifier: 0x4a Timestamp: 14646 Subpixel: no subpixels Clones: CRTCs: 3 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: ``` I tested this on multiple machines and on both Debian 9 and 10 (with X11, not wayland). Is this a bug, or what is the explanation for this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From csoren at isd.net Tue Oct 15 23:42:31 2019 From: csoren at isd.net (Chris Sorenson) Date: Tue, 15 Oct 2019 18:42:31 -0500 Subject: Using Intel GPU "TearFree" option changes my detected screens / edid information In-Reply-To: References: Message-ID: <53b3594470875f4f75829943d687b3ab@cpinternet.com> > > I tested this on multiple machines and on both Debian 9 and 10 (with > X11, > not wayland). Is this a bug, or what is the explanation for this? > Reply to both list an OP. I did a diff on those two xrandr outputs, there's a lot going on there. Intel is very wishy-washy about their graphics drivers. First thing to check would probably be how far off your Debian is compared to what Intel thinks your system should be using with their drivers (hyperlink): https://01.org/linuxgraphics/downloads/2018q1-intel-graphics-stack-recipe From zarniwhoop at ntlworld.com Wed Oct 16 00:50:51 2019 From: zarniwhoop at ntlworld.com (Ken Moffat) Date: Wed, 16 Oct 2019 01:50:51 +0100 Subject: Bounce message including details for lots of people Message-ID: <20191016005051.GB21040@milliways.localdomain> I've received bounce messages (not unusual with my isp, they have severely broken commercial filters), but I was not expecting to see details of the *many* recipients who apparently bounced a message due to DMARC failures re a message from isp.net. ĸen -- Truth, in front of her huge walk-in wardrobe, selected black leather boots with stiletto heels for such a barefaced truth. - Unseen Academicals From ml+xorg at esmtp.org Wed Oct 16 01:22:40 2019 From: ml+xorg at esmtp.org (Claus Assmann) Date: Tue, 15 Oct 2019 18:22:40 -0700 Subject: Bounce message including details for lots of people In-Reply-To: <20191016005051.GB21040@milliways.localdomain> References: <20191016005051.GB21040@milliways.localdomain> Message-ID: <20191016012240.GA17287@x2.esmtp.org> On Wed, Oct 16, 2019, Ken Moffat wrote: > I've received bounce messages (not unusual with my isp, they have "bounce messages" for mails going to this list? Those should go to the envelope sender (xorg-bounces at lists.x.org), not some address in a header. Sounds like some broken software (geez, what a surprise)? > due to DMARC failures re a message from isp.net. DMARC -- since this is not a list about e-mail, I refrain from making comments about it... From zarniwhoop at ntlworld.com Wed Oct 16 04:45:23 2019 From: zarniwhoop at ntlworld.com (Ken Moffat) Date: Wed, 16 Oct 2019 05:45:23 +0100 Subject: Bounce message including details for lots of people In-Reply-To: <20191016012240.GA17287@x2.esmtp.org> References: <20191016005051.GB21040@milliways.localdomain> <20191016012240.GA17287@x2.esmtp.org> Message-ID: <20191016044523.GA25733@milliways.localdomain> On Tue, Oct 15, 2019 at 06:22:40PM -0700, Claus Assmann wrote: > On Wed, Oct 16, 2019, Ken Moffat wrote: > > I've received bounce messages (not unusual with my isp, they have > > "bounce messages" for mails going to this list? Those should go to > the envelope sender (xorg-bounces at lists.x.org), not some address > in a header. Sounds like some broken software (geez, what a surprise)? > Actually it was a probe message because of bounces (to unsubscribe me if I had not received it). But _from_ xorg-bounces+.... > > due to DMARC failures re a message from isp.net. > > DMARC -- since this is not a list about e-mail, I refrain > from making comments about it... True. -- Truth, in front of her huge walk-in wardrobe, selected black leather boots with stiletto heels for such a barefaced truth. - Unseen Academicals From mrmazda at earthlink.net Wed Oct 16 02:53:13 2019 From: mrmazda at earthlink.net (Felix Miata) Date: Tue, 15 Oct 2019 22:53:13 -0400 Subject: Using Intel GPU "TearFree" option changes my detected screens / edid information In-Reply-To: References: Message-ID: <4e79168d-1aaf-52b8-d9c2-cc7dd0601289@earthlink.net> Seba Kerckhof composed on 2019-10-15 16:34 (UTC+0200): > I was experiencing tearing on my Debian system. I read about the intel > driver "TearFree" option and configured it as explained here: > https://wiki.archlinux.org/index.php/Intel_graphics#Tearing > While it does seem to help with the tearing, it changes my detected > screens. By this I mean if I run xrandr, my display ports have a different > name and the detected screens have a different EDID (model/vendor), > different resolutions etc. You apparently weren't using the Intel DDX, but the (default) modesetting DDX. By applying: /etc/X11/xorg.conf.d/20-intel.conf Section "Device" Identifier "Intel Graphics" Driver "intel" Option "TearFree" "true" EndSection you switched to the Intel DDX, which uses a different naming convention. The modesetting DDX's names work the same for Intel, AMD and NVidia GPUs. Why vendor:model would change I have no idea. The Intel DDX hasn't had an official release in over 4 years, while Intel's DDX writers are significant contributors to the modesetting DDX. It seems as though the Intel DDX is informally deprecated. I've been using it exclusively where supported in spite of tearing (on Haswell), which doesn't really bother me. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ From ajax at redhat.com Thu Oct 17 16:06:37 2019 From: ajax at redhat.com (Adam Jackson) Date: Thu, 17 Oct 2019 12:06:37 -0400 Subject: [ANNOUNCE] xorgproto 2019.2 Message-ID: <404a6ab9ed0a45e9bc1cdb7253db94823166dba7.camel@redhat.com> This release moves more header files to the legacy set. Note that this means libX11 older than 1.6.9 and libXvMC older than 1.0.12 will not build without some legacy headers installed. Adam Jackson (2): Move remaining xlib-entwined headers to LEGACY xorgproto 2019.2 Jon Turney (1): Move windowswmproto to legacy git tag: xorgproto-2019.2 https://xorg.freedesktop.org/archive/individual/proto/xorgproto-2019.2.tar.bz2 MD5: a02dcaff48b4141b949ac99dfc344d86 xorgproto-2019.2.tar.bz2 SHA1: 2dedbe3e4daccf0c3d675759ed82161a3e4cf1b5 xorgproto-2019.2.tar.bz2 SHA256: 46ecd0156c561d41e8aa87ce79340910cdf38373b759e737fcbba5df508e7b8e xorgproto-2019.2.tar.bz2 SHA512: cbfdf6bb3d58d4d4e7788c9ed779402352715e9899f65594fbc527b3178f1dc5e03cebc8ba5a863b3c196a1a0f2026c2d0438207ca19f81f3c8b7da0c0667904 xorgproto-2019.2.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/proto/xorgproto-2019.2.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/proto/xorgproto-2019.2.tar.gz MD5: 8b26b966abfa322d3dbaea75d89ad5a2 xorgproto-2019.2.tar.gz SHA1: 59b055dae3d556153b65ddf929db4d35bf9cb17d xorgproto-2019.2.tar.gz SHA256: ebfcfce48b66bec25d5dff0e9510e04053ef78e51a8eabeeee4c00e399226d61 xorgproto-2019.2.tar.gz SHA512: 3385e7eb8ae1384aa01945c7f5a300884a1deb8d564ab62bd5bcaa3703d3dbf9bbc19797ac17d19e15417bf8456f706f993e90ece2d34cc94046ac302c062cbe xorgproto-2019.2.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/proto/xorgproto-2019.2.tar.gz.sig - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part URL: From matej.bjgar at atlas.cz Tue Oct 22 07:38:09 2019 From: matej.bjgar at atlas.cz (matej.bjgar at atlas.cz) Date: Tue, 22 Oct 2019 09:38:09 +0200 Subject: =?utf-8?q?How_to_submit_XKB_layout_variant_to_Xorg=3F?= Message-ID: <20191022093809.F8273B99@atlas.cz> I added a custom XKB layout variant to /usr/share/X11/xkb/rules/xorg.lst and /usr/share/X11/xkb/symbols/cz. I can set it using setxkbmap and it works. When I upgrade my distribution or update Xorg, the variant is gone. From what I've read, I concluded I can't reliably add a custom variant (or any layout modification) to XKB. My variant is Colemak optimised for writing Czech letters. Some languages have its own Colemak variant in preinstalled layouts but not Czech and anyone typing with Colemak in Czech can use it. What has to be done to have a variant added for distribution with Xorg? The only answer I found is at https://lists.freedesktop.org/archives/xorg/2007-July/026537.html but the link in that letter leads to a site with text “Sorry, entering a bug into the product xkeyboard-config has been disabled.” I'll be thankful for information relevant to this, especially for an answer to my question or some information about how to reliably add keyboard variant to XKB. Matěj Bagar From alan.coopersmith at oracle.com Tue Oct 22 15:27:00 2019 From: alan.coopersmith at oracle.com (Alan Coopersmith) Date: Tue, 22 Oct 2019 08:27:00 -0700 Subject: How to submit XKB layout variant to Xorg? In-Reply-To: <20191022093809.F8273B99@atlas.cz> References: <20191022093809.F8273B99@atlas.cz> Message-ID: <45b2f28f-0e90-d202-0053-77f39c3f7feb@oracle.com> On 10/22/19 12:38 AM, matej.bjgar at atlas.cz wrote: > I added a custom XKB layout variant to /usr/share/X11/xkb/rules/xorg.lst and /usr/share/X11/xkb/symbols/cz. I can set it using setxkbmap and it works. When I upgrade my distribution or update Xorg, the variant is gone. From what I've read, I concluded I can't reliably add a custom variant (or any layout modification) to XKB. > > My variant is Colemak optimised for writing Czech letters. Some languages have its own Colemak variant in preinstalled layouts but not Czech and anyone typing with Colemak in Czech can use it. > > What has to be done to have a variant added for distribution with Xorg? See: https://www.freedesktop.org/wiki/Software/XKeyboardConfig/ especially the link to submission rules & code repositories. -- -Alan Coopersmith- alan.coopersmith at oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc From zboszor at pr.hu Tue Oct 22 15:50:21 2019 From: zboszor at pr.hu (=?UTF-8?B?QsO2c3rDtnJtw6lueWkgWm9sdMOhbg==?=) Date: Tue, 22 Oct 2019 17:50:21 +0200 Subject: UDL device cannot get its own screen Message-ID: <536af56f-924d-f089-a2d8-180f4dee1613@pr.hu> Hi, I have the below configuration for an Intel based POS system that, while advertises 3 outputs (DP1, VGA1 and HDMI1 with xf86-video-intel), only two are usable. DP1 for the built-in touchscreen and VGA1 for the external VGA connector. I wanted to use an USB DisplayLink device as the 3rd output, with all three output using its own Screen number, i.e. :0.0 :0.1 and :0.2. The first observation is that I can't seem to be able to use the Intel DDX driver in conjunction with the modesetting DDX that the UDL device uses. The symptom is that two modesetting outputs are initialized, one for UDL and one for the disconnected HDMI1 Intel output. At least now the X server don't crash as with Xorg 1.19.x with a similar attempt. The second is that when the modesetting driver is used, the Intel outputs are renamed from VGA1 to VGA-1 and so on, i.e. the outputs get an extra "-" between the output type and the number so it needed extra typing to port the original config from intel to modesetting. The third observation is that while I am using this configuration below, so the UDL device should be assigned to :0.2 (and active!), it is really assigned to :0[.0] as an inactive output. See that there's no "*" indicator set for any of the supported modes on DVI-I-1-1. How can I set up 3 different Screens correctly for 3 separate fullscreen applications? I am using Xorg 1.20.4 patched with the "autobind GPUs to the screen" patch from Dave Airlie that at least wakes up the UDL device and makes it visible without extra magic with providers/sinks. # DISPLAY=:0 xrandr Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192 DP-1 connected primary 1024x768+0+0 (normal left inverted right x axis y axis) 304mm x 228mm 1024x768 60.00*+ DVI-I-1-1 connected (normal left inverted right x axis y axis) 1024x768 75.03 + 60.00 1920x1080 60.00 + 1680x1050 59.88 1280x1024 75.02 60.02 1440x900 74.98 59.90 1280x720 60.00 800x600 75.00 60.32 640x480 75.00 72.81 66.67 59.94 720x400 70.08 1024x768 (0x4a) 65.000MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.36KHz v: height 768 start 771 end 777 total 806 clock 60.00Hz # cat /etc/X11/xorg.conf.d/videocard.conf Section "Monitor" Identifier "Monitor-DP-1" Option "AutoServerLayout" "on" Option "Rotate" "normal" EndSection Section "Monitor" Identifier "Monitor-HDMI-1" Option "AutoServerLayout" "on" Option "Rotate" "normal" EndSection Section "Monitor" Identifier "Monitor-VGA-1" Option "AutoServerLayout" "on" Option "Rotate" "normal" EndSection Section "Monitor" Identifier "DVI-I-1-1" Option "AutoServerLayout" "on" Option "Rotate" "normal" EndSection Section "Device" Identifier "Intel0" Driver "modesetting" Option "kmsdev" "/dev/dri/card1" Screen 0 Option "Monitor-DP1" "DP-1" Option "ZaphodHeads" "DP-1" EndSection Section "Device" Identifier "Intel1" Driver "modesetting" Option "kmsdev" "/dev/dri/card1" Screen 1 Option "Monitor-VGA-1" "VGA-1" Option "ZaphodHeads" "VGA-1" EndSection # Intentionally not referenced in ServerLayout below Section "Device" Identifier "Intel2" Driver "modesetting" Option "kmsdev" "/dev/dri/card1" Option "Monitor-HDMI-1" "HDMI-1" Option "ZaphodHeads" "HDMI-1" EndSection Section "Device" Identifier "UDL" Driver "modesetting" Option "kmsdev" "/dev/dri/card0" Screen 2 Option "Monitor-DVI-I-1-1" "DVI-I-1-1" EndSection Section "Screen" Identifier "SCREEN" Option "AutoServerLayout" "on" Device "Intel0" Monitor "Monitor-DP-1" SubSection "Display" Modes "1024x768" Depth 24 EndSubSection EndSection Section "Screen" Identifier "SCREEN1" Option "AutoServerLayout" "on" Device "Intel1" Monitor "Monitor-VGA-1" SubSection "Display" Modes "1024x768" Depth 24 EndSubSection EndSection Section "Screen" Identifier "SCREEN2" Option "AutoServerLayout" "on" Device "UDL" Monitor "Monitor-DVI-I-1-1" SubSection "Display" Modes "1024x768" Depth 24 EndSubSection EndSection Section "ServerLayout" Identifier "LAYOUT" Option "AutoServerLayout" "on" Screen 0 "SCREEN" Screen 1 "SCREEN1" RightOf "SCREEN" Screen 2 "SCREEN2" RightOf "SCREEN1" EndSection Best regards, Zoltán Böszörményi From zboszor at pr.hu Wed Oct 23 06:41:05 2019 From: zboszor at pr.hu (=?UTF-8?B?QsO2c3rDtnJtw6lueWkgWm9sdMOhbg==?=) Date: Wed, 23 Oct 2019 08:41:05 +0200 Subject: UDL device cannot get its own screen In-Reply-To: References: <536af56f-924d-f089-a2d8-180f4dee1613@pr.hu> Message-ID: <35cdaafe-461e-56ec-d3d3-47fdd6468251@pr.hu> 2019. 10. 22. 22:57 keltezéssel, Ilia Mirkin írta: > On Tue, Oct 22, 2019 at 11:50 AM Böszörményi Zoltán wrote: >> >> Hi, >> >> I have the below configuration for an Intel based POS system that, >> while advertises 3 outputs (DP1, VGA1 and HDMI1 with xf86-video-intel), >> only two are usable. DP1 for the built-in touchscreen and VGA1 for >> the external VGA connector. >> >> I wanted to use an USB DisplayLink device as the 3rd output, with all >> three output using its own Screen number, i.e. :0.0 :0.1 and :0.2. >> >> [...] >> >> How can I set up 3 different Screens correctly for 3 separate fullscreen >> applications? >> >> I am using Xorg 1.20.4 patched with the "autobind GPUs to the screen" >> patch from Dave Airlie that at least wakes up the UDL device and makes >> it visible without extra magic with providers/sinks. > > If it's being treated as a GPU, that's your first problem for this > kind of setup. You should see modeset(2), in your logs, but I suspect > you're seeing modeset(G0) (the "G" indicates "GPU"). modeset(2) is the unconnected HDMI-1 output advertised by the Intel chip. modeset(G0) is UDL. > >> >> [...] >> Section "Monitor" >> Identifier "DVI-I-1-1" > > The others are Monitor-*, this one isn't. You probably want this to be > DVI-I-1, as noted below. I guess you get the extra -1 from seeing it > as a slaved GPU's output in your current configuration. Indeed. Fixed. > >> Option "AutoServerLayout" "on" >> Option "Rotate" "normal" >> EndSection >> >> [...] >> >> Section "Device" >> Identifier "UDL" >> Driver "modesetting" >> Option "kmsdev" "/dev/dri/card0" >> Screen 2 >> Option "Monitor-DVI-I-1-1" "DVI-I-1-1" > > I think you have an extra -1 in here (and the monitor name doesn't > exist as per above). And I think the "Screen" index is wrong -- it's > not what one tends to think it is, as I recall. I think you can just > drop these lines though. Without "Screen N" lines, all the outputs are assigned to :0 so the screen layout setup in the ServerLayout section is not applied properly. I have read Dave Airlie's patch (that has been accepted into Xorg 1.21.0) more closely, and it indeed binds UDL to DISPLAY=:0 I think this patch needs a followup patch so it would use the screen ID specified in the Device section. > >> EndSection >> >> [...] >> >> Section "ServerLayout" >> Identifier "LAYOUT" >> Option "AutoServerLayout" "on" >> Screen 0 "SCREEN" >> Screen 1 "SCREEN1" RightOf "SCREEN" >> Screen 2 "SCREEN2" RightOf "SCREEN1" >> EndSection >> >> Best regards, >> Zoltán Böszörményi >> _______________________________________________ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel From ppaalanen at gmail.com Wed Oct 23 07:42:25 2019 From: ppaalanen at gmail.com (Pekka Paalanen) Date: Wed, 23 Oct 2019 10:42:25 +0300 Subject: UDL device cannot get its own screen In-Reply-To: <536af56f-924d-f089-a2d8-180f4dee1613@pr.hu> References: <536af56f-924d-f089-a2d8-180f4dee1613@pr.hu> Message-ID: <20191023104225.60f969a0@eldfell.localdomain> On Tue, 22 Oct 2019 17:50:21 +0200 Böszörményi Zoltán wrote: > Hi, > > I have the below configuration for an Intel based POS system that, > while advertises 3 outputs (DP1, VGA1 and HDMI1 with xf86-video-intel), > only two are usable. DP1 for the built-in touchscreen and VGA1 for > the external VGA connector. > > I wanted to use an USB DisplayLink device as the 3rd output, with all > three output using its own Screen number, i.e. :0.0 :0.1 and :0.2. ... > The third observation is that while I am using this configuration below, > so the UDL device should be assigned to :0.2 (and active!), it is really > assigned to :0[.0] as an inactive output. See that there's no "*" indicator > set for any of the supported modes on DVI-I-1-1. > > How can I set up 3 different Screens correctly for 3 separate fullscreen > applications? > > I am using Xorg 1.20.4 patched with the "autobind GPUs to the screen" > patch from Dave Airlie that at least wakes up the UDL device and makes > it visible without extra magic with providers/sinks. Hi, for your specific use case, auto-bind is exactly what you do not want. So drop the patch or (since the patch is in upstream master already) use the option it adds to stop auto-binding. Thanks, pq -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From imirkin at alum.mit.edu Tue Oct 22 20:57:02 2019 From: imirkin at alum.mit.edu (Ilia Mirkin) Date: Tue, 22 Oct 2019 16:57:02 -0400 Subject: UDL device cannot get its own screen In-Reply-To: <536af56f-924d-f089-a2d8-180f4dee1613@pr.hu> References: <536af56f-924d-f089-a2d8-180f4dee1613@pr.hu> Message-ID: On Tue, Oct 22, 2019 at 11:50 AM Böszörményi Zoltán wrote: > > Hi, > > I have the below configuration for an Intel based POS system that, > while advertises 3 outputs (DP1, VGA1 and HDMI1 with xf86-video-intel), > only two are usable. DP1 for the built-in touchscreen and VGA1 for > the external VGA connector. > > I wanted to use an USB DisplayLink device as the 3rd output, with all > three output using its own Screen number, i.e. :0.0 :0.1 and :0.2. > > [...] > > How can I set up 3 different Screens correctly for 3 separate fullscreen > applications? > > I am using Xorg 1.20.4 patched with the "autobind GPUs to the screen" > patch from Dave Airlie that at least wakes up the UDL device and makes > it visible without extra magic with providers/sinks. If it's being treated as a GPU, that's your first problem for this kind of setup. You should see modeset(2), in your logs, but I suspect you're seeing modeset(G0) (the "G" indicates "GPU"). > > # cat /etc/X11/xorg.conf.d/videocard.conf > Section "Monitor" > Identifier "Monitor-DP-1" > Option "AutoServerLayout" "on" > Option "Rotate" "normal" > EndSection > > Section "Monitor" > Identifier "Monitor-HDMI-1" > Option "AutoServerLayout" "on" > Option "Rotate" "normal" > EndSection > > Section "Monitor" > Identifier "Monitor-VGA-1" > Option "AutoServerLayout" "on" > Option "Rotate" "normal" > EndSection > > Section "Monitor" > Identifier "DVI-I-1-1" The others are Monitor-*, this one isn't. You probably want this to be DVI-I-1, as noted below. I guess you get the extra -1 from seeing it as a slaved GPU's output in your current configuration. > Option "AutoServerLayout" "on" > Option "Rotate" "normal" > EndSection > > Section "Device" > Identifier "Intel0" > Driver "modesetting" > Option "kmsdev" "/dev/dri/card1" > Screen 0 > Option "Monitor-DP1" "DP-1" > Option "ZaphodHeads" "DP-1" > EndSection > > Section "Device" > Identifier "Intel1" > Driver "modesetting" > Option "kmsdev" "/dev/dri/card1" > Screen 1 > Option "Monitor-VGA-1" "VGA-1" > Option "ZaphodHeads" "VGA-1" > EndSection > > # Intentionally not referenced in ServerLayout below > Section "Device" > Identifier "Intel2" > Driver "modesetting" > Option "kmsdev" "/dev/dri/card1" > Option "Monitor-HDMI-1" "HDMI-1" > Option "ZaphodHeads" "HDMI-1" > EndSection > > Section "Device" > Identifier "UDL" > Driver "modesetting" > Option "kmsdev" "/dev/dri/card0" > Screen 2 > Option "Monitor-DVI-I-1-1" "DVI-I-1-1" I think you have an extra -1 in here (and the monitor name doesn't exist as per above). And I think the "Screen" index is wrong -- it's not what one tends to think it is, as I recall. I think you can just drop these lines though. > EndSection > > Section "Screen" > Identifier "SCREEN" > Option "AutoServerLayout" "on" > Device "Intel0" > Monitor "Monitor-DP-1" > SubSection "Display" > Modes "1024x768" > Depth 24 > EndSubSection > EndSection > > Section "Screen" > Identifier "SCREEN1" > Option "AutoServerLayout" "on" > Device "Intel1" > Monitor "Monitor-VGA-1" > SubSection "Display" > Modes "1024x768" > Depth 24 > EndSubSection > EndSection > > Section "Screen" > Identifier "SCREEN2" > Option "AutoServerLayout" "on" > Device "UDL" > Monitor "Monitor-DVI-I-1-1" > SubSection "Display" > Modes "1024x768" > Depth 24 > EndSubSection > EndSection > > Section "ServerLayout" > Identifier "LAYOUT" > Option "AutoServerLayout" "on" > Screen 0 "SCREEN" > Screen 1 "SCREEN1" RightOf "SCREEN" > Screen 2 "SCREEN2" RightOf "SCREEN1" > EndSection > > Best regards, > Zoltán Böszörményi > _______________________________________________ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel From petri at digip.org Wed Oct 23 08:18:09 2019 From: petri at digip.org (Petri Lehtinen) Date: Wed, 23 Oct 2019 11:18:09 +0300 Subject: How to submit XKB layout variant to Xorg? In-Reply-To: <20191022093809.F8273B99@atlas.cz> References: <20191022093809.F8273B99@atlas.cz> Message-ID: Hi! > I added a custom XKB layout variant to /usr/share/X11/xkb/rules/xorg.lst and /usr/share/X11/xkb/symbols/cz. I can set it using setxkbmap and it works. When I upgrade my distribution or update Xorg, the variant is gone. If you add your variant as a new symbols file, e.g. /usr/share/X11/xkb/symbols/mycz, you can enable it with setxkbmap -layout mycz and upgrading your distribution or xorg packages won't probably remove that file. You don't even need to duplicate the cz symbols. You can just use the include directive to include the sections you need from the cz symbols file (or any other symbols file) and add your own customizations. Petri From zboszor at pr.hu Wed Oct 23 12:12:03 2019 From: zboszor at pr.hu (=?UTF-8?B?QsO2c3rDtnJtw6lueWkgWm9sdMOhbg==?=) Date: Wed, 23 Oct 2019 14:12:03 +0200 Subject: UDL device cannot get its own screen In-Reply-To: <20191023104225.60f969a0@eldfell.localdomain> References: <536af56f-924d-f089-a2d8-180f4dee1613@pr.hu> <20191023104225.60f969a0@eldfell.localdomain> Message-ID: 2019. 10. 23. 9:42 keltezéssel, Pekka Paalanen írta: > On Tue, 22 Oct 2019 17:50:21 +0200 > Böszörményi Zoltán wrote: > >> Hi, >> >> I have the below configuration for an Intel based POS system that, >> while advertises 3 outputs (DP1, VGA1 and HDMI1 with xf86-video-intel), >> only two are usable. DP1 for the built-in touchscreen and VGA1 for >> the external VGA connector. >> >> I wanted to use an USB DisplayLink device as the 3rd output, with all >> three output using its own Screen number, i.e. :0.0 :0.1 and :0.2. > > ... > >> The third observation is that while I am using this configuration below, >> so the UDL device should be assigned to :0.2 (and active!), it is really >> assigned to :0[.0] as an inactive output. See that there's no "*" indicator >> set for any of the supported modes on DVI-I-1-1. >> >> How can I set up 3 different Screens correctly for 3 separate fullscreen >> applications? >> >> I am using Xorg 1.20.4 patched with the "autobind GPUs to the screen" >> patch from Dave Airlie that at least wakes up the UDL device and makes >> it visible without extra magic with providers/sinks. > > Hi, > > for your specific use case, auto-bind is exactly what you do not want. > So drop the patch or (since the patch is in upstream master already) > use the option it adds to stop auto-binding. With Option "AutoBindGPU" "false" in effect (equivalent of backing the patch out) the UDL device does not get assigned to ANY of the screens. I want it to have its own :0.2 bit that doesn't happen. > > > Thanks, > pq > From ppaalanen at gmail.com Wed Oct 23 12:42:02 2019 From: ppaalanen at gmail.com (Pekka Paalanen) Date: Wed, 23 Oct 2019 15:42:02 +0300 Subject: UDL device cannot get its own screen In-Reply-To: References: <536af56f-924d-f089-a2d8-180f4dee1613@pr.hu> <20191023104225.60f969a0@eldfell.localdomain> Message-ID: <20191023154202.051cd87c@eldfell.localdomain> On Wed, 23 Oct 2019 14:12:03 +0200 Böszörményi Zoltán wrote: > 2019. 10. 23. 9:42 keltezéssel, Pekka Paalanen írta: > > On Tue, 22 Oct 2019 17:50:21 +0200 > > Böszörményi Zoltán wrote: > > > >> Hi, > >> > >> I have the below configuration for an Intel based POS system that, > >> while advertises 3 outputs (DP1, VGA1 and HDMI1 with xf86-video-intel), > >> only two are usable. DP1 for the built-in touchscreen and VGA1 for > >> the external VGA connector. > >> > >> I wanted to use an USB DisplayLink device as the 3rd output, with all > >> three output using its own Screen number, i.e. :0.0 :0.1 and :0.2. > > > > ... > > > >> The third observation is that while I am using this configuration below, > >> so the UDL device should be assigned to :0.2 (and active!), it is really > >> assigned to :0[.0] as an inactive output. See that there's no "*" indicator > >> set for any of the supported modes on DVI-I-1-1. > >> > >> How can I set up 3 different Screens correctly for 3 separate fullscreen > >> applications? > >> > >> I am using Xorg 1.20.4 patched with the "autobind GPUs to the screen" > >> patch from Dave Airlie that at least wakes up the UDL device and makes > >> it visible without extra magic with providers/sinks. > > > > Hi, > > > > for your specific use case, auto-bind is exactly what you do not want. > > So drop the patch or (since the patch is in upstream master already) > > use the option it adds to stop auto-binding. > > With Option "AutoBindGPU" "false" in effect (equivalent of backing the > patch out) the UDL device does not get assigned to ANY of the screens. > > I want it to have its own :0.2 bit that doesn't happen. Yes, that's another problem. Autobind=false is a step in the right direction, but apparently not sufficient. Thanks, pq -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From imirkin at alum.mit.edu Wed Oct 23 13:32:53 2019 From: imirkin at alum.mit.edu (Ilia Mirkin) Date: Wed, 23 Oct 2019 09:32:53 -0400 Subject: UDL device cannot get its own screen In-Reply-To: <35cdaafe-461e-56ec-d3d3-47fdd6468251@pr.hu> References: <536af56f-924d-f089-a2d8-180f4dee1613@pr.hu> <35cdaafe-461e-56ec-d3d3-47fdd6468251@pr.hu> Message-ID: On Wed, Oct 23, 2019 at 2:41 AM Böszörményi Zoltán wrote: > > 2019. 10. 22. 22:57 keltezéssel, Ilia Mirkin írta: > > On Tue, Oct 22, 2019 at 11:50 AM Böszörményi Zoltán wrote: > >> Section "Device" > >> Identifier "UDL" > >> Driver "modesetting" > >> Option "kmsdev" "/dev/dri/card0" > >> Screen 2 > >> Option "Monitor-DVI-I-1-1" "DVI-I-1-1" > > > > I think you have an extra -1 in here (and the monitor name doesn't > > exist as per above). And I think the "Screen" index is wrong -- it's > > not what one tends to think it is, as I recall. I think you can just > > drop these lines though. > > Without "Screen N" lines, all the outputs are assigned to :0 > so the screen layout setup in the ServerLayout section is not > applied properly. > As I remember it, the Screen here is for ZaphodHeads-type configurations, and it indicates which head you're supposed to use of the underlying device. My suggestion was to only remove it here, not everywhere. -ilia From petri at digip.org Thu Oct 24 07:37:08 2019 From: petri at digip.org (Petri Lehtinen) Date: Thu, 24 Oct 2019 10:37:08 +0300 Subject: Key repeat does not work in XKB with EIGHT_LEVEL Message-ID: <20191024073708.GA253491@ping.localdomain> Hi! I use a custom xkb_symbols file that employs the EIGHT_LEVEL type to add various helpers behind ISO_Level3_Shift and ISO_Level5_Shift. Everything works fine, expect when I set this layout as the default in xorg.conf, key repeat stops working. The keys mapped in my xkb_symbols file simply don't repeat, whereas keys my config doesn't change (that are defined in xkb/symbols/pc) repeat normally. If I don't set any Xkb* options in xorg.conf and use setxkbmap to switch to this layout, then key repeat works normally. I can manually enable key repeat after starting X by running `xset r KEY` for each KEY between 8 and 255. I also have to run it if I plug in an external USB keyboard, or otherwise key repeat doesn't work in the plugged in keyboard. Any ideas why this happens, and how I could debug this problem and seek for a fix? Petri From alan.coopersmith at oracle.com Sun Oct 27 16:37:49 2019 From: alan.coopersmith at oracle.com (Alan Coopersmith) Date: Sun, 27 Oct 2019 09:37:49 -0700 Subject: [fdo] xorg-xf86-input-keyboard license In-Reply-To: <1796817819.933975.1572181979548.JavaMail.yahoo@mail.yahoo.co.jp> References: <1796817819.933975.1572181979548.JavaMail.yahoo.ref@mail.yahoo.co.jp> <1796817819.933975.1572181979548.JavaMail.yahoo@mail.yahoo.co.jp> Message-ID: [I've cc'ed the xorg mailing list, where this is a much more on-topic question than the freedesktop general mailing list.] On 10/27/19 6:12 AM, 布施 博明 wrote: > Hello > > I am developing X application now > I have one question about xorg-xf86-input-keyboard license Why do you care about the server license if you're writing an application (i.e. a client)? > I checked following file > > https://github.com/freedesktop/xorg-xf86-input-keyboard/blob/master/COPYING > > This file show MIT licene > > And I found following file > > https://github.com/freedesktop/xorg-xf86-input-keyboard/blob/master/src/lnx_kbd.c > > >   * Portions based on kbdrate.c from util-linux 2.9t, which is >  * Copyright 1992 Rickard E. Faith.  Distributed under the GPL. >  * This program comes with ABSOLUTELY NO WARRANTY We should probably delete lnx_kbd.c, both to give license clarity and to stop people from thinking it's a useful driver to have on Linux systems any more. If you're building the X server for a Linux box you want either the libinput or evdev drivers instead of keyboard. If you're building for something without a Linux kernel, then you won't be building the lnx_kbd.c file any way. -- -Alan Coopersmith- alan.coopersmith at oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc From alan.coopersmith at oracle.com Sun Oct 27 17:15:21 2019 From: alan.coopersmith at oracle.com (Alan Coopersmith) Date: Sun, 27 Oct 2019 10:15:21 -0700 Subject: [fdo] xorg-xf86-input-keyboard license In-Reply-To: <935220203ac26b12c94ef41073df8e60.squirrel@softorchestra.com> References: <1796817819.933975.1572181979548.JavaMail.yahoo.ref@mail.yahoo.co.jp> <1796817819.933975.1572181979548.JavaMail.yahoo@mail.yahoo.co.jp> <935220203ac26b12c94ef41073df8e60.squirrel@softorchestra.com> Message-ID: <455a6ce4-7dae-6ffd-803b-eee6bc88b1aa@oracle.com> On 10/27/19 10:07 AM, Alan DuBoff wrote: > On Sun, October 27, 2019 9:37 am, Alan Coopersmith wrote: >> Why do you care about the server license if you're writing an application >> (i.e. a client)? > > Not the OP, but I will tell you why it is important. You explained the GPL, which I well understand, but not why someone working on client software cares about the license of something on the server side. GPL does not require clients to follow the licensing conditions of servers they connect to. > Obviously a long answer to the GPL point of licensing. Please consider the > long term and how it will effect people that use opensource, and especially > Xorg drivers. Xorg has a well established license policy, and I didn't invite a debate on it. Debates about Microsoft & Linux licensing are off-topic here. -- -Alan Coopersmith- alan.coopersmith at oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc From aland at SoftOrchestra.com Sun Oct 27 17:23:30 2019 From: aland at SoftOrchestra.com (Alan DuBoff) Date: Sun, 27 Oct 2019 10:23:30 -0700 (PDT) Subject: [fdo] xorg-xf86-input-keyboard license In-Reply-To: <455a6ce4-7dae-6ffd-803b-eee6bc88b1aa@oracle.com> References: <1796817819.933975.1572181979548.JavaMail.yahoo.ref@mail.yahoo.co.jp> <1796817819.933975.1572181979548.JavaMail.yahoo@mail.yahoo.co.jp> <935220203ac26b12c94ef41073df8e60.squirrel@softorchestra.com> <455a6ce4-7dae-6ffd-803b-eee6bc88b1aa@oracle.com> Message-ID: On Sun, 27 Oct 2019, Alan Coopersmith wrote: > You explained the GPL, which I well understand, but not why someone > working on client software cares about the license of something on > the server side. GPL does not require clients to follow the licensing > conditions of servers they connect to. Why should anyone care about software protection at all then? The reason is because as I stated, the GPL requires you follow specific guidelines in the use and publishing of the sources. This may or may not be a reason for Xorg to use it or not, that is not up to me to decide. I merely suggest Xorg consider their license useage closely. As for debating ms/linux, it was only used as an example, no reason to dwell on it. -- Regards, Alan From aland at SoftOrchestra.com Sun Oct 27 17:26:38 2019 From: aland at SoftOrchestra.com (Alan DuBoff) Date: Sun, 27 Oct 2019 10:26:38 -0700 (PDT) Subject: [fdo] xorg-xf86-input-keyboard license In-Reply-To: <455a6ce4-7dae-6ffd-803b-eee6bc88b1aa@oracle.com> References: <1796817819.933975.1572181979548.JavaMail.yahoo.ref@mail.yahoo.co.jp> <1796817819.933975.1572181979548.JavaMail.yahoo@mail.yahoo.co.jp> <935220203ac26b12c94ef41073df8e60.squirrel@softorchestra.com> <455a6ce4-7dae-6ffd-803b-eee6bc88b1aa@oracle.com> Message-ID: On Sun, 27 Oct 2019, Alan Coopersmith wrote: > GPL does not require clients to follow the licensing conditions of > servers they connect to. In regard to this point, I will just point out that I advocate the use of GPL as a form of protection, and the input drivers should fall into that category. If a company takes an input driver and modifies it, they should be required to publish their sources. That's my $0.02. -- Regards, Alan From aland at softorchestra.com Sun Oct 27 17:07:33 2019 From: aland at softorchestra.com (Alan DuBoff) Date: Sun, 27 Oct 2019 10:07:33 -0700 Subject: [fdo] xorg-xf86-input-keyboard license In-Reply-To: References: <1796817819.933975.1572181979548.JavaMail.yahoo.ref@mail.yahoo.co.jp> <1796817819.933975.1572181979548.JavaMail.yahoo@mail.yahoo.co.jp> Message-ID: <935220203ac26b12c94ef41073df8e60.squirrel@softorchestra.com> On Sun, October 27, 2019 9:37 am, Alan Coopersmith wrote: > Why do you care about the server license if you're writing an application > (i.e. a client)? Not the OP, but I will tell you why it is important. GPL, as you know, is put in place to protect the opensource aspect of the code, and as such requires the changes be published for modifications that are done on top of the existing drivers/sources. Although this is violated all the time, the entire reason the conditions are put in place is to keep everyone honest. If not for that, everyone would be similar to Huawei. Currently Huawei is in the news and being scrutinized over taking IP, and I couldn't agree more. I once interviewed at Huawei and I was asked how I felt about taking Linux sources and porting them to FreeBSD without putting the changes back to the Linux repositories? Well, I didn't have the warm fuzzies about that to be honest, because it is in violation of the GPL. >> https://github.com/freedesktop/xorg-xf86-input-keyboard/blob/master/src/lnx_kbd.c >> >> >>   * Portions based on kbdrate.c from util-linux 2.9t, which is >>  * Copyright 1992 Rickard E. Faith.  Distributed under the GPL. >>  * This program comes with ABSOLUTELY NO WARRANTY > > We should probably delete lnx_kbd.c, both to give license clarity and to > stop > people from thinking it's a useful driver to have on Linux systems any more. That I can't answer for you, but remember that the one way to keep folks honest is to require they post their changes, which the GPL does. If you go back to the 2.4.17 kernel, which is right around the time the GPL requirement was really starting to be enforced, there was a lot of screaming from folks about the exporting of GPL definitions in drivers, I was one of them. These basically governed how drivers were to be handled within the opensource realm. In the case of an Xorg input driver, they are drivers, just that they run in user space. The question becomes how you want you sources to be protected under the opensource umbrella. I used to think the GPL was bad, in the way it is infectious. However, here we are almost 20 years after the fact and we see people trying to take sources without putting their changes back all the time. People like microsoft now include entire Linux subsystems to install on their operating system. While this environment is fragile, it still uses a good lump of opensource code. In return the Linux community is lucky to get basic git communication with TFS. It seems microsoft is more take than give. Obviously a long answer to the GPL point of licensing. Please consider the long term and how it will effect people that use opensource, and especially Xorg drivers. Honestly, I can't believe I'm defending the GPL after close to 20 years when it started to change with GPL2 and GPL3, but I now believe it is for all of or good. I see better why Stallman changed the conditions of the GPL now. Alan From Andrew.R.Nelson at leidos.com Mon Oct 28 16:49:57 2019 From: Andrew.R.Nelson at leidos.com (Nelson, Andrew R.) Date: Mon, 28 Oct 2019 16:49:57 +0000 Subject: Issue with multitouch monitors and xcb_grab/ungrab_pointer. Message-ID: <8d9179b1b46245a6a9d8915e3aa35277@leidos.com> Leidos Proprietary We are encountering an issue with Xorg 1.17.2 (Yes I know it is very old). 1. Compile the attached program [gcc touchbug.c -o touchbug -lxcb] 2. Run the program [./touchbug ] 3. Move the mouse over the application window, notice the console output indicates no buttons are pressed. 4. Press and hold the mouse in the window created by the attached program (this will grab the pointer). 5. Without releasing the mouse generate a touch event outside of the window (this will ungrab the pointer). 6. Move the mouse over the window (notice the console output indicates Button1 is pressed). I would have expected, in step 6, the console output would again indicate no button is pressed. I've tried this with xscope between the example application and the xserver and xscope indicates the motion events sent by the XServer are also reporting Button1 is pressed. I have though noticed [xinput --query-state ] for the mouse indicates all buttons are "up". It appears this issue has been fixed in Xorg 1.20.4 (at least I'm not seeing the issue on a upgraded workstation that happens to have a later version of Xorg). What I'm trying to figure out is what component might be involved in this issue (XServer, XInputExtention, Kernel Driver)? Is the issue core to the Xserver or is this because the XInput extension has somehow modified the events so that XCB cannot read them correctly? Is it possible anyone has heard of this issue and can point to where it was fixed? Is it possible we have somehow misconfigured our XServer? Thanks, Andrew Nelson This email and any attachments to it are intended only for the identified recipients. It may contain proprietary or otherwise legally protected information of Leidos. Any unauthorized use or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete or otherwise destroy the email and all attachments immediately. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: touchbug.c URL: From ajax at redhat.com Tue Oct 29 20:20:15 2019 From: ajax at redhat.com (Adam Jackson) Date: Tue, 29 Oct 2019 16:20:15 -0400 Subject: [fdo] xorg-xf86-input-keyboard license In-Reply-To: References: <1796817819.933975.1572181979548.JavaMail.yahoo.ref@mail.yahoo.co.jp> <1796817819.933975.1572181979548.JavaMail.yahoo@mail.yahoo.co.jp> Message-ID: On Sun, 2019-10-27 at 09:37 -0700, Alan Coopersmith wrote: > We should probably delete lnx_kbd.c, both to give license clarity and to stop > people from thinking it's a useful driver to have on Linux systems any more. > > If you're building the X server for a Linux box you want either the libinput > or evdev drivers instead of keyboard. If you're building for something without > a Linux kernel, then you won't be building the lnx_kbd.c file any way. Seconded: https:/gitlab.freedesktop.org/xorg/driver/xf86-input-keyboard/merge_requests/1 This does mean any future releases will need to be done from a non- Linux host, since it will no longer build. - ajax