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: