Re: What to do with base X11 for netbsd-9 ?
On Fri, 7 Jun 2019, John D. Baker wrote: > I'm now running with "xf86-video-intel-2014" and it works great so far. > I've not really stressed it yet but so far it works well with default > SNA acceleration. I've turned off TearFree for now to save the performance > penalty. > > [ 457.198] (--) intel(0): Integrated Graphics Chipset: Intel(R) G41 > > [ 457.199] (II) intel(0): SNA initialized with Eaglelake (gen4.5) backend I finally got the i82946GZ machine set up again. It reports: [ 232.831] (--) intel(0): Integrated Graphics Chipset: Intel(R) 946GZ [ 232.917] (II) intel(0): SNA initialized with Broadwater (gen4) backend Again, with the "new" (2019?) version of xf86-video-intel, it had the same problems previously described (i.e., SNA is broken on these older-but-not-old-enough chips). With the 2014 version it works great and I can turn off "TearFree" to save the performance hit. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: What to do with base X11 for netbsd-9 ?
Patrick Welche wrote: >On Mon, Jun 10, 2019 at 05:36:37PM +0200, Michael van Elst wrote: >> On Mon, Jun 10, 2019 at 03:42:10PM +0100, Patrick Welche wrote: >> > It doesn't seem to help. Another difference is that consdev com0 works >> > for the biosboot, but not for efiboot, which means I can't be sure >> > where nouveau gets stuck. >> >> Maybe EFI doesn't initialize com0. With e.g. >> >> consdev com,0x3f8,9600 >> >> this is done by the bootloader and might work. > >I didn't notice a difference. When I run consdev, the screen clears >and I get a new prompt, but still on the screen. (Tried with and without >the 0x, and tried 2f8) > >I noticed that when pressing the power switch, the computer powered down >immediately, so there is probably more to it than a happy computer with >no screen display. Does the keyboard work ? And can you choose which boot method is used from the same installation ? If the keyboard works you could use DDB to flush the dmesg to disk before rebooting. >From memory that is how I got nouveau working on one of my systems, it would panic after clearing the screen.
Re: What to do with base X11 for netbsd-9 ?
On Mon, Jun 10, 2019 at 05:36:37PM +0200, Michael van Elst wrote: > On Mon, Jun 10, 2019 at 03:42:10PM +0100, Patrick Welche wrote: > > It doesn't seem to help. Another difference is that consdev com0 works > > for the biosboot, but not for efiboot, which means I can't be sure > > where nouveau gets stuck. > > Maybe EFI doesn't initialize com0. With e.g. > > consdev com,0x3f8,9600 > > this is done by the bootloader and might work. I didn't notice a difference. When I run consdev, the screen clears and I get a new prompt, but still on the screen. (Tried with and without the 0x, and tried 2f8) I noticed that when pressing the power switch, the computer powered down immediately, so there is probably more to it than a happy computer with no screen display. Cheers, Patrick
Re: What to do with base X11 for netbsd-9 ?
On Mon, Jun 10, 2019 at 03:42:10PM +0100, Patrick Welche wrote: > It doesn't seem to help. Another difference is that consdev com0 works > for the biosboot, but not for efiboot, which means I can't be sure > where nouveau gets stuck. Maybe EFI doesn't initialize com0. With e.g. consdev com,0x3f8,9600 this is done by the bootloader and might work. Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: What to do with base X11 for netbsd-9 ?
On Wed, Jun 05, 2019 at 09:55:08AM -, Michael van Elst wrote: > pr...@cam.ac.uk (Patrick Welche) writes: > > >This has changed! The above is still true with EFI, but with BIOS booting, > >nouveau attaches successfully, and I can run xdm+twm! > > What happens in EFI mode when, before booting the kernel you configure > a display mode with the 'gop' command ? It doesn't seem to help. Another difference is that consdev com0 works for the biosboot, but not for efiboot, which means I can't be sure where nouveau gets stuck. Cheers, Patrick
Re: What to do with base X11 for netbsd-9 ?
On Thu, 6 Jun 2019, John D. Baker wrote: > I think for my next update I'll switch to building the old intel (2014?) > driver on amd64 and see how that goes. I'm now running with "xf86-video-intel-2014" and it works great so far. I've not really stressed it yet but so far it works well with default SNA acceleration. I've turned off TearFree for now to save the performance penalty. [ 457.198] (--) intel(0): Integrated Graphics Chipset: Intel(R) G41 [ 457.199] (II) intel(0): SNA initialized with Eaglelake (gen4.5) backend -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: What to do with base X11 for netbsd-9 ?
mlel...@serpens.de (Michael van Elst) writes: >some visible padding. Now there is no padding between font and field >border. Now there is. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: What to do with base X11 for netbsd-9 ?
jdba...@consolidated.net ("John D. Baker") writes:
>Now, it is too far to the left, with the central vertical bar almost
>adjacent to the left border. The crossbars at the top and bottom of
>the edit cursor glitch the left border where they cross it.
You are right. The cursor was two pixels off to the left, I just
fixed that.
>The font it chose seems uncomfortably large for the size of the
>edit field. Indeed, the entire greeter widget seems cramped and
It choses the fonts for prompt and text and then sizes the edit
fields to these two fonts.
Previously it miscalculated sizes which caused it to misplace the
characters in relation to the border. Now it does an exact calculation.
The previous guesswork may or may not have accidentially introduced
some visible padding. Now there is no padding between font and field
border.
But since the calculation is now exact, we can add some padding.
>the CLIENTHOST (which is the FQDN in my case) makes the greet message
>extend to the left quite a way. It used not to do that.
It did sometimes. I now made the widget is a little bit wider so
that the message neither touches or trashes the border.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
re: What to do with base X11 for netbsd-9 ?
> I think for my next update I'll switch to building the old intel (2014?) > driver on amd64 and see how that goes. yes - please let me know how the 2014 driver goes for you with -current. i haven't yet attempted to bisect these, but if it's the clear cause of your regressions, i'll push bisect up my queue. .mrg.
Re: What to do with base X11 for netbsd-9 ?
As to the 'xdm' edit fields issue. I've finally had a chance to try it and they are still broken, but differently. Before the edit cursor was too low, glitching the bottom border of the field. Now, it is too far to the left, with the central vertical bar almost adjacent to the left border. The crossbars at the top and bottom of the edit cursor glitch the left border where they cross it. The font it chose seems uncomfortably large for the size of the edit field. Indeed, the entire greeter widget seems cramped and the CLIENTHOST (which is the FQDN in my case) makes the greet message extend to the left quite a way. It used not to do that. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: What to do with base X11 for netbsd-9 ?
Likewise, for the i82Q45-based machine under netbsd-8: [274876.079] (--) intel(0): Integrated Graphics Chipset: Intel(R) Q45/Q43 [274876.129] (II) intel(0): SNA initialized with Eaglelake (gen4.5) backend which works fine. Under -current (8.99.42): [ 100.548] (--) intel(0): Integrated Graphics Chipset: Intel(R) Q45/Q43 [ 100.618] (II) intel(0): SNA initialized with Eaglelake (gen4.5) backend which doesn't work. I suppose I could try the i82946GZ system as well, but it will probably show the same thing (has same behavior. Again, forcing the AccelMethod to "UXA" works around the problem, but it seems clear that SNA used to work with these chips and now doesn't. I think for my next update I'll switch to building the old intel (2014?) driver on amd64 and see how that goes. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: What to do with base X11 for netbsd-9 ?
My HP Envy laptop boots NetBSD-current in EFI mode for quite some time now, perhaps a year. The GeForce 950M doesn't work, as expected, but the Intel 530 now works perfectly fine with full 3D acceleration and quite decent full screen video. On Wed, 5 Jun 2019 at 20:32, Frank Kardel wrote: > > Same EFI issue here: EFI/GK208B [GeForce GT 710] gets stuck when > attempting to configure the card. > > Booting via CSM or EFI and nouveau disabled gets the machine up and > nouveau works fine with acceleration in the CSM case. > > Looking at the PCI configuration the main difference is that the CSM > sets the BusMaster bits to enabled on the bridges while this is not the > case for EFI. > > Also more IO/MEM/ROM bits are set. > > I think we still lack sufficient PCI setup when booting via EFI. > > (lspci dumps are available on request). > > Frank > > > On 06/05/19 11:25, Patrick Welche wrote: > > On Tue, Jun 04, 2019 at 01:03:49PM +0100, Patrick Welche wrote: > >> On another front, I cannot boot a computer with nouveau and a > >> NVidia GeForce GTX 680 (GK104). At the point where the console normally > >> changes resolution, the screen goes black and everything stops. > >> (No panic AFAICT) > > This has changed! The above is still true with EFI, but with BIOS booting, > > nouveau attaches successfully, and I can run xdm+twm! The experience > > is exactly the opposite to the one with Sandy Bridge: images display fine, > > glmark2 runs. It's the fonts which are unreadable (not a question of size > > but of artifacts. This is in 3840x mode. Still, at least I no longer > > have to disable nouveau in order to boot! > > > > Cheers, > > > > Patrick > --
Re: What to do with base X11 for netbsd-9 ?
Same EFI issue here: EFI/GK208B [GeForce GT 710] gets stuck when attempting to configure the card. Booting via CSM or EFI and nouveau disabled gets the machine up and nouveau works fine with acceleration in the CSM case. Looking at the PCI configuration the main difference is that the CSM sets the BusMaster bits to enabled on the bridges while this is not the case for EFI. Also more IO/MEM/ROM bits are set. I think we still lack sufficient PCI setup when booting via EFI. (lspci dumps are available on request). Frank On 06/05/19 11:25, Patrick Welche wrote: On Tue, Jun 04, 2019 at 01:03:49PM +0100, Patrick Welche wrote: On another front, I cannot boot a computer with nouveau and a NVidia GeForce GTX 680 (GK104). At the point where the console normally changes resolution, the screen goes black and everything stops. (No panic AFAICT) This has changed! The above is still true with EFI, but with BIOS booting, nouveau attaches successfully, and I can run xdm+twm! The experience is exactly the opposite to the one with Sandy Bridge: images display fine, glmark2 runs. It's the fonts which are unreadable (not a question of size but of artifacts. This is in 3840x mode. Still, at least I no longer have to disable nouveau in order to boot! Cheers, Patrick
Re: What to do with base X11 for netbsd-9 ?
On Wed, May 29, 2019 at 09:12:42AM +0200, Martin Husemann wrote: > Hey folks, > > I would like to get your feedback about the current state of the base X11, > as there have been lots of threads about various issues and I have lost > the overview of what works in -current and what does not. > > We *really* need to branch netbsd-9 very soon now, and it is unclear (at > least to me) what should happen to the in-tree X11 version. > > - we have very obvious display bugs at first sight in xdm > - self hosting builds on 4 GB amd64 machines are not really possible >any more (due to LLVM runtime dependencies, which can not even be >disabled at build time right now) > - reports here (and on other lists) about display problems and success >stories have no clear winner (but probably due to me losing track) > > So what is you story/opinion: is base X11 usable in -current? If not, > what needs to be done or what hardware needs fixes? FWIW, on a recent Dell laptop: [ 1.03] cpu0 at mainbus0 apid 0 [ 1.03] cpu0: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz, id 0x806e9 [ 1.014344] i915drmkms0 at pci0 dev 2 function 0: vendor 8086 product 5916 (rev. 0x02) With current I can now use stellarium and opencpn with hardware accelleration, which is a real improvement over netbsd-8 (stellarium now gives me 60fps, when without hardware accelleration it's a less than 1 - almost unusable). -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: What to do with base X11 for netbsd-9 ?
pr...@cam.ac.uk (Patrick Welche) writes: >This has changed! The above is still true with EFI, but with BIOS booting, >nouveau attaches successfully, and I can run xdm+twm! What happens in EFI mode when, before booting the kernel you configure a display mode with the 'gop' command ? -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: What to do with base X11 for netbsd-9 ?
On Tue, Jun 04, 2019 at 01:03:49PM +0100, Patrick Welche wrote: > On another front, I cannot boot a computer with nouveau and a > NVidia GeForce GTX 680 (GK104). At the point where the console normally > changes resolution, the screen goes black and everything stops. > (No panic AFAICT) This has changed! The above is still true with EFI, but with BIOS booting, nouveau attaches successfully, and I can run xdm+twm! The experience is exactly the opposite to the one with Sandy Bridge: images display fine, glmark2 runs. It's the fonts which are unreadable (not a question of size but of artifacts. This is in 3840x mode. Still, at least I no longer have to disable nouveau in order to boot! Cheers, Patrick
Re: What to do with base X11 for netbsd-9 ?
* matthew green : > Lars Reichardt writes: > > > > > matthew green hat am 4. Juni 2019 um 07:19 > > > geschrieben: > > > > > > > > > unfortunately, you need the as-yet non-functional amdgpu driver > > > i believe: > > > > > > [ 1594.209] (--) RADEON(0): Chipset: "OLAND" (ChipID = 0x6613) > > > > > > means a GCN v1. radeon supports this minimally, but the GL does > > > not. > > > > > > > > > .mrg. > > > > afaik those GCN v1 chips are supported by radeon and have experimental > > support via amdgpu. > > > > It fails with glamor xorg disabled llvmpipe, some quick search hint in > > the direction of mesa build options. > > > > The same hardware works under Linux with both drivers accelerated. > > > > The kernel driver loads the OLAND_mc2.bin firmware but fails to load > > TAHITI_vce.bin (I guess it's for video decoding) which is missing from > > the filesystem maybe that's causing some hickup. > > ah yes - i forget how the overlaps between radeon and amdgpu > are and this one should be (only) in radeon as 'radeonsi'. > > can you try installing TAHITI_vce.bin and seeing what happens? > it seems unlikely to be the problem. > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/radeon > > if this doesn't help, we'll have to see what is up in Mesa. > > > .mrg. unfortunately it fails now with: [ 4.695688] radeon0: autoconfiguration error: error: VCE init error (-22). but not complaining about the missing vce fw anymore I'll try the modular-xorg maybe that show a different behavior and some pointer. Lars -- You will continue to suffer if you have an emotional reaction to everything that is said to you. True power is sitting back and observing everything with logic. If words control you that means everyone else can control you. Breathe and allow things to pass. --- Bruce Lee
Re: What to do with base X11 for netbsd-9 ?
On Sat, Jun 01, 2019 at 08:01:26PM +1000, matthew green wrote: ... > so, i just updated a few X11 packages in -current. as part > of testing, i ran them on the sandy bridge laptop i've seen > display glitches with the new intel driver on (mate-terminal). > > these glitches are now gone. > > can anyone with intel driver issues please try again with > -current? this may not help much older devices, but maybe > it helps sorta older (eg, sandy bridge) systems?. Tried with the old sandy bridge again: [ 819.027] (II) Module intel: vendor="X.Org Foundation" [ 819.027]compiled for 1.20.5, module version = 2.99.917 ... [ 819.039] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 30 00 [ 819.039] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3, sse4.1, sse4.2, avx; using a maximum of 2 threads ... [ 819.040] (II) intel(0): SNA initialized with Sandybridge (gen6, gt2) backend Before all the updates, e.g. last year, it worked with SNA and no TearFree. Now, when displaying images, e.g., with GraphicsMagick, I see horizontal line segments which eventually get filled in. Otherwise, e.g., all the xterms in the world, work fine, as do e.g. 2 copies of glmark2, with a score of 182. Work arounds include (all with TearFree off): - switch to UXA (glmark2 score of 50) - switch to modesetting driver (glmark2 score of 50) On another front, I cannot boot a computer with nouveau and a NVidia GeForce GTX 680 (GK104). At the point where the console normally changes resolution, the screen goes black and everything stops. (No panic AFAICT) Cheers, Patrick
re: What to do with base X11 for netbsd-9 ?
Lars Reichardt writes: > > > matthew green hat am 4. Juni 2019 um 07:19 geschrieben: > > > > > > unfortunately, you need the as-yet non-functional amdgpu driver > > i believe: > > > > [ 1594.209] (--) RADEON(0): Chipset: "OLAND" (ChipID = 0x6613) > > > > means a GCN v1. radeon supports this minimally, but the GL does > > not. > > > > > > .mrg. > > afaik those GCN v1 chips are supported by radeon and have experimental > support via amdgpu. > > It fails with glamor xorg disabled llvmpipe, some quick search hint in > the direction of mesa build options. > > The same hardware works under Linux with both drivers accelerated. > > The kernel driver loads the OLAND_mc2.bin firmware but fails to load > TAHITI_vce.bin (I guess it's for video decoding) which is missing from > the filesystem maybe that's causing some hickup. ah yes - i forget how the overlaps between radeon and amdgpu are and this one should be (only) in radeon as 'radeonsi'. can you try installing TAHITI_vce.bin and seeing what happens? it seems unlikely to be the problem. https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/radeon if this doesn't help, we'll have to see what is up in Mesa. .mrg.
re: What to do with base X11 for netbsd-9 ?
> matthew green hat am 4. Juni 2019 um 07:19 geschrieben: > > > unfortunately, you need the as-yet non-functional amdgpu driver > i believe: > > [ 1594.209] (--) RADEON(0): Chipset: "OLAND" (ChipID =3D 0x6613) > > means a GCN v1. radeon supports this minimally, but the GL does > not. > > > .mrg. afaik those GCN v1 chips are supported by radeon and have experimental support via amdgpu. It fails with glamor xorg disabled llvmpipe, some quick search hint in the direction of mesa build options. The same hardware works under Linux with both drivers accelerated. The kernel driver loads the OLAND_mc2.bin firmware but fails to load TAHITI_vce.bin (I guess it's for video decoding) which is missing from the filesystem maybe that's causing some hickup. Lars
re: What to do with base X11 for netbsd-9 ?
unfortunately, you need the as-yet non-functional amdgpu driver i believe: [ 1594.209] (--) RADEON(0): Chipset: "OLAND" (ChipID =3D 0x6613) means a GCN v1. radeon supports this minimally, but the GL does not. .mrg.
Re: What to do with base X11 for netbsd-9 ?
* Robert Swindells : > > Lars Reichardt wrote: > >On Sun, 2 Jun 2019 09:35:02 +0200 > >Lars Reichardt wrote: > > > >> Hi there, > >> > >> for me netbsd-current as of yesterday with an upto date xsrc looks > >> stable (light desktop use and a quick check of glxgears which runs > >> accelerated). > >> > >> Hardware consists of a ryzen 7 2700 and an amd radeon, > >> OLAND (0x1002:0x6613 0x1043:0x0543). > >> > > > >But I haven't yet found a way to enable 2d acceleration... > > Modern GPUs don't do 2d acceleration. Any 2d operations are done in > software using a mix of 3d primitives and basic GPU instructions. > > What are you expecting to see ? It does run software only no glamor acceleration. direct rendring is disabled please find attached the Xorg.0.log Lars [ 1594.185] X.Org X Server 1.20.5 X Protocol Version 11, Revision 0 [ 1594.185] Build Operating System: NetBSD/amd64 8.99.42 - The NetBSD Foundation, Inc. [ 1594.185] Current Operating System: NetBSD aoide.paradoxon.local 8.99.42 NetBSD 8.99.42 (AOIDE) #7: Mon Jun 3 21:28:53 CEST 2019 root@aoide.paradoxon.local:/usr/src/sys/arch/amd64/compile/AOIDE amd64 [ 1594.185] Build Date: 03 March 2019 07:11:23AM [ 1594.186] [ 1594.187] Current version of pixman: 0.38.4 [ 1594.187]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 1594.187] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 1594.187] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Jun 4 06:47:18 2019 [ 1594.187] (==) Using config file: "/etc/X11/xorg.conf" [ 1594.187] (==) ServerLayout "X.org Configured" [ 1594.187] (**) |-->Screen "Screen0" (0) [ 1594.187] (**) | |-->Monitor "Monitor0" [ 1594.187] (**) | |-->Device "Card0" [ 1594.187] (**) |-->Input Device "Mouse0" [ 1594.187] (**) |-->Input Device "Keyboard0" [ 1594.187] (==) Not automatically adding devices [ 1594.187] (==) Not automatically enabling devices [ 1594.187] (==) Not automatically adding GPU devices [ 1594.187] (==) Max clients allowed: 256, resource mask: 0x1f [ 1594.188] (WW) The directory "/usr/pkg/share/fonts/X11/misc" does not exist. [ 1594.188]Entry deleted from font path. [ 1594.188] (WW) `fonts.dir' not found (or not valid) in "/usr/pkg/share/fonts/X11/OTF". [ 1594.188]Entry deleted from font path. [ 1594.188](Run 'mkfontdir' on "/usr/pkg/share/fonts/X11/OTF"). [ 1594.188] (WW) The directory "/usr/pkg/share/fonts/X11/Type1" does not exist. [ 1594.188]Entry deleted from font path. [ 1594.188] (WW) The directory "/usr/pkg/share/fonts/X11/100dpi" does not exist. [ 1594.188]Entry deleted from font path. [ 1594.188] (WW) The directory "/usr/pkg/share/fonts/X11/75dpi" does not exist. [ 1594.188]Entry deleted from font path. [ 1594.188] (WW) The directory "/usr/pkg/share/fonts/X11/cyrillic" does not exist. [ 1594.188]Entry deleted from font path. [ 1594.188] (**) FontPath set to: /usr/X11R7/lib/X11/fonts/misc/, /usr/X11R7/lib/X11/fonts/TTF/, /usr/X11R7/lib/X11/fonts/Type1/, /usr/X11R7/lib/X11/fonts/75dpi/, /usr/X11R7/lib/X11/fonts/100dpi/, /usr/pkg/share/fonts/X11/TTF, /usr/X11R7/lib/X11/fonts/misc/, /usr/X11R7/lib/X11/fonts/TTF/, /usr/X11R7/lib/X11/fonts/Type1/, /usr/X11R7/lib/X11/fonts/75dpi/, /usr/X11R7/lib/X11/fonts/100dpi/ [ 1594.188] (**) ModulePath set to "/usr/X11R7/lib/modules" [ 1594.188] (II) Loader magic: 0x150e8ea20 [ 1594.188] (II) Module ABI versions: [ 1594.188]X.Org ANSI C Emulation: 0.4 [ 1594.188]X.Org Video Driver: 24.0 [ 1594.188]X.Org XInput driver : 24.1 [ 1594.188]X.Org Server Extension : 10.0 [ 1594.199] (--) PCI:*(8@8:0:0) 1002:6613:1043:0543 rev 0, Mem @ 0xe000/268435456, 0xfe90/262144, I/O @ 0xd000/256, BIOS @ 0x/131072 [ 1594.199] (II) "glx" will be loaded. This was enabled by default and also specified in the config file. [ 1594.199] (II) LoadModule: "dri" [ 1594.199] (II) Module "dri" already built-in [ 1594.199] (II) LoadModule: "dri2" [ 1594.199] (II) Module "dri2" already built-in [ 1594.199] (II) LoadModule: "glx" [ 1594.200] (II) Loading /usr/X11R7/lib/modules/extensions/libglx.so [ 1594.200] (II) Module glx: vendor="X.Org Foundation" [ 1594.200]compiled for 1.20.5, module version = 1.0.0 [ 1594.200]ABI class: X.Org Server Extension, version 10.0 [ 1594.200] (II) LoadModule: "shadow" [ 1594.200] (II) Loading /usr/X11R7/lib/modules/extensions/libshadow.so [ 1594.200] (II) Module shadow: vendor="X.Org Foundation" [ 1594.200]compiled for 1.20.5, module version = 1.1.0 [ 1594.200]ABI class: X.Org ANSI C Emulation, version 0.4 [ 1594.200] (II) LoadModule: "radeon" [ 1594.200] (II) Loading /usr/X11R7/lib/modules/drivers/radeon_drv.s
Re: What to do with base X11 for netbsd-9 ?
On Mon, 3 Jun 2019, John D. Baker wrote: > On Sat, 1 Jun 2019, John D. Baker wrote: > > > On Wed, 29 May 2019, m...@netbsd.org wrote: > > > > > Is your problem that your hardware is too old to be using SNA but it's > > > still picked? > > > > This appears to have been exactly the case. Snippets from "Xorg.0.log" > > w/o any "xorg.conf": > > > > [687526.365] (--) intel(0): Integrated Graphics Chipset: Intel(R) G41 > > > > [687526.415] (II) intel(0): SNA initialized with Eaglelake (gen4.5) backend > > On netbsd-8, the intel driver works properly, no "xorg.conf" required. > As a sanity check, I looked at the Xorg.0.log for netbsd-8 (8.1_STABLE) > and it shows: > > [94.206] (--) intel(0): Integrated Graphics Chipset: Intel(R) G41 > > [95.071] (II) intel(0): SNA initialized with Eaglelake (gen4.5) backend > > So SNA not working in the driver in -current would appear to be a > regression. For the machine with a real i82915 which works fine under -current: [ 1002.035] (--) intel(0): Integrated Graphics Chipset: Intel(R) 915G [ 1002.038] (II) intel(0): SNA initialized with Alviso (gen3) backend -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: What to do with base X11 for netbsd-9 ?
On Sat, 1 Jun 2019, John D. Baker wrote: > On Wed, 29 May 2019, m...@netbsd.org wrote: > > > Is your problem that your hardware is too old to be using SNA but it's > > still picked? > > This appears to have been exactly the case. Snippets from "Xorg.0.log" > w/o any "xorg.conf": > > [687526.365] (--) intel(0): Integrated Graphics Chipset: Intel(R) G41 > > [687526.415] (II) intel(0): SNA initialized with Eaglelake (gen4.5) backend On netbsd-8, the intel driver works properly, no "xorg.conf" required. As a sanity check, I looked at the Xorg.0.log for netbsd-8 (8.1_STABLE) and it shows: [94.206] (--) intel(0): Integrated Graphics Chipset: Intel(R) G41 [95.071] (II) intel(0): SNA initialized with Eaglelake (gen4.5) backend So SNA not working in the driver in -current would appear to be a regression. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: What to do with base X11 for netbsd-9 ?
Lars Reichardt wrote: >On Sun, 2 Jun 2019 09:35:02 +0200 >Lars Reichardt wrote: > >> Hi there, >> >> for me netbsd-current as of yesterday with an upto date xsrc looks >> stable (light desktop use and a quick check of glxgears which runs >> accelerated). >> >> Hardware consists of a ryzen 7 2700 and an amd radeon, >> OLAND (0x1002:0x6613 0x1043:0x0543). >> > >But I haven't yet found a way to enable 2d acceleration... Modern GPUs don't do 2d acceleration. Any 2d operations are done in software using a mix of 3d primitives and basic GPU instructions. What are you expecting to see ?
Re: What to do with base X11 for netbsd-9 ?
On 01.06.2019 23:08, m...@netbsd.org wrote: > On Sun, Jun 02, 2019 at 07:05:10AM +1000, matthew green wrote: >>> I haven't made any corruption related fixes. >> >> neither did i :-) we did both change a bunch of things though, and >> i was surprised that i could not reproduce the prior mate-terminal >> corrruption. > > in the original discussion I mentioned that the corruption almost goes > away by keeping a second instance doing 3d acceleration (like running > a second glmark2 will make both glmark2 instances not corrupt) > After upgrade I see no improvement with my hardware. The older laptop actually is probably hanging and it's not responding. I need to address one ptrace issue in the kernel and for now I need to ignore it and allow loading of one of my laptops 1-60min. Once I will get some spare time I will debug it. signature.asc Description: OpenPGP digital signature
re: What to do with base X11 for netbsd-9 ?
> - self hosting builds on 4 GB amd64 machines are not really possible >any more (due to LLVM runtime dependencies, which can not even be >disabled at build time right now) FWIW, you can now build x86 with MKLLVMRT=no and it will build complete sets that are merely missing functionality. eg, you will lose llvmpipe and AMD GL support, but Xvideo will remain functional (so movies), and it builds much faster. .mrg.
Re: What to do with base X11 for netbsd-9 ?
On Sun, 2 Jun 2019 09:35:02 +0200 Lars Reichardt wrote: > Hi there, > > for me netbsd-current as of yesterday with an upto date xsrc looks > stable (light desktop use and a quick check of glxgears which runs > accelerated). > > Hardware consists of a ryzen 7 2700 and an amd radeon, > OLAND (0x1002:0x6613 0x1043:0x0543). > But I haven't yet found a way to enable 2d acceleration... > greetings, > Lars > > * Martin Husemann : > > Hey folks, > > > > I would like to get your feedback about the current state of the > > base X11, as there have been lots of threads about various issues > > and I have lost the overview of what works in -current and what > > does not. > > > > We *really* need to branch netbsd-9 very soon now, and it is > > unclear (at least to me) what should happen to the in-tree X11 > > version. > > > > - we have very obvious display bugs at first sight in xdm > > - self hosting builds on 4 GB amd64 machines are not really > > possible any more (due to LLVM runtime dependencies, which can not > > even be disabled at build time right now) > > - reports here (and on other lists) about display problems and > > success stories have no clear winner (but probably due to me losing > > track) > > > > So what is you story/opinion: is base X11 usable in -current? If > > not, what needs to be done or what hardware needs fixes? > > > > Martin -- Mystische Erklärungen: Die mystischen Erklärungen gelten für tief; die Wahrheit ist, dass sie noch nicht einmal oberflächlich sind. -- Friedrich Nietzsche [ Die Fröhliche Wissenschaft Buch 3, 126 ]
Re: What to do with base X11 for netbsd-9 ?
Hi there, for me netbsd-current as of yesterday with an upto date xsrc looks stable (light desktop use and a quick check of glxgears which runs accelerated). Hardware consists of a ryzen 7 2700 and an amd radeon, OLAND (0x1002:0x6613 0x1043:0x0543). greetings, Lars * Martin Husemann : > Hey folks, > > I would like to get your feedback about the current state of the base X11, > as there have been lots of threads about various issues and I have lost > the overview of what works in -current and what does not. > > We *really* need to branch netbsd-9 very soon now, and it is unclear (at > least to me) what should happen to the in-tree X11 version. > > - we have very obvious display bugs at first sight in xdm > - self hosting builds on 4 GB amd64 machines are not really possible >any more (due to LLVM runtime dependencies, which can not even be >disabled at build time right now) > - reports here (and on other lists) about display problems and success >stories have no clear winner (but probably due to me losing track) > > So what is you story/opinion: is base X11 usable in -current? If not, > what needs to be done or what hardware needs fixes? > > Martin
Re: What to do with base X11 for netbsd-9 ?
On Sun, 2 Jun 2019, m...@netbsd.org wrote: > Well, it does have *a lot* of code related to generation 4 SNA support. I > guess it's meant to work. The manual page does say: "UXA" (Unified Acceleration Architecture) is the mature backend that was introduced to support the GEM driver model. It is in the process of being superseded by "SNA" (Sandybridge's New Acceleration). Until that process is complete, the ability to choose which backend to use remains for backwards compatibility. So while it may be meant to work it apparently does not yet for some devices or the devices are mis-detected as supporting SNA. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: What to do with base X11 for netbsd-9 ?
Well, it does have *a lot* of code related to generation 4 SNA support. I guess it's meant to work.
Re: What to do with base X11 for netbsd-9 ?
On Wed, 29 May 2019, m...@netbsd.org wrote: > Is your problem that your hardware is too old to be using SNA but it's > still picked? This appears to have been exactly the case. Snippets from "Xorg.0.log" w/o any "xorg.conf": [687526.365] (--) intel(0): Integrated Graphics Chipset: Intel(R) G41 [687526.415] (II) intel(0): SNA initialized with Eaglelake (gen4.5) backend I explicitly set: Option "AccelMethod" "UXA" and it worked perfectly. Once that was shown, I could then set: Option "TearFree" "false" to save the performance penalty. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: What to do with base X11 for netbsd-9 ?
On Sun, Jun 02, 2019 at 07:05:10AM +1000, matthew green wrote: > > I haven't made any corruption related fixes. > > neither did i :-) we did both change a bunch of things though, and > i was surprised that i could not reproduce the prior mate-terminal > corrruption. in the original discussion I mentioned that the corruption almost goes away by keeping a second instance doing 3d acceleration (like running a second glmark2 will make both glmark2 instances not corrupt)
re: What to do with base X11 for netbsd-9 ?
> I haven't made any corruption related fixes. neither did i :-) we did both change a bunch of things though, and i was surprised that i could not reproduce the prior mate-terminal corrruption.
Re: What to do with base X11 for netbsd-9 ?
On Sat, Jun 01, 2019 at 09:41:28PM +1000, matthew green wrote: > > I've updated my two intel gpu laptops like 3-4 days ago and I see no > > improvement. Glitches are on one laptop and on the other one X window > > starts in 1-60min, depending on some random timeout to expire. Should I > > upgrade again and recheck? I planned to debug the X code once I will > > sort out other fallout after my upgrade (mostly with things in pkgsrc). > > i think so. > > i last tested the sandy bridge laptop a couple of weeks ago and > it was still not great. maya@ has fixed a bunch of issues in > addition to the newer versions so there are a lot of fixes in > just the last couple of days. > > thanks! > > > .mrg. I haven't made any corruption related fixes.
Re: What to do with base X11 for netbsd-9 ?
На 2019-06-01 в 12:33, Kamil Rytarowski написа: > On 01.06.2019 12:01, matthew green wrote: >> so, i just updated a few X11 packages in -current. as part >> of testing, i ran them on the sandy bridge laptop i've seen >> display glitches with the new intel driver on (mate-terminal). >> >> these glitches are now gone. >> >> can anyone with intel driver issues please try again with >> -current? this may not help much older devices, but maybe >> it helps sorta older (eg, sandy bridge) systems?. >> >> thanks. >> > I've updated my two intel gpu laptops like 3-4 days ago and I see no > improvement. Glitches are on one laptop and on the other one X window > starts in 1-60min, depending on some random timeout to expire. Should I > upgrade again and recheck? I planned to debug the X code once I will > sort out other fallout after my upgrade (mostly with things in pkgsrc). > In my case, on Skylake, I see almost no problems, apart from a few minor glitches with gdm and kdm. Slim and xdm appear perfect. 3D acceleration works very well indeed (right now I am running the aquarium webgl demo under Firefox 67.0 and four copies of glmark2). So it is getting there.
Re: What to do with base X11 for netbsd-9 ?
On 01.06.2019 12:01, matthew green wrote: > so, i just updated a few X11 packages in -current. as part > of testing, i ran them on the sandy bridge laptop i've seen > display glitches with the new intel driver on (mate-terminal). > > these glitches are now gone. > > can anyone with intel driver issues please try again with > -current? this may not help much older devices, but maybe > it helps sorta older (eg, sandy bridge) systems?. > > thanks. > I've updated my two intel gpu laptops like 3-4 days ago and I see no improvement. Glitches are on one laptop and on the other one X window starts in 1-60min, depending on some random timeout to expire. Should I upgrade again and recheck? I planned to debug the X code once I will sort out other fallout after my upgrade (mostly with things in pkgsrc). signature.asc Description: OpenPGP digital signature
re: What to do with base X11 for netbsd-9 ?
> I've updated my two intel gpu laptops like 3-4 days ago and I see no > improvement. Glitches are on one laptop and on the other one X window > starts in 1-60min, depending on some random timeout to expire. Should I > upgrade again and recheck? I planned to debug the X code once I will > sort out other fallout after my upgrade (mostly with things in pkgsrc). i think so. i last tested the sandy bridge laptop a couple of weeks ago and it was still not great. maya@ has fixed a bunch of issues in addition to the newer versions so there are a lot of fixes in just the last couple of days. thanks! .mrg.
re: What to do with base X11 for netbsd-9 ?
> - we have very obvious display bugs at first sight in xdm these seem fixed now. it would be nice to get a better way to update Xresources for the other bug related to the update. thanks mlelstv@. > - reports here (and on other lists) about display problems and success >stories have no clear winner (but probably due to me losing track) so, i just updated a few X11 packages in -current. as part of testing, i ran them on the sandy bridge laptop i've seen display glitches with the new intel driver on (mate-terminal). these glitches are now gone. can anyone with intel driver issues please try again with -current? this may not help much older devices, but maybe it helps sorta older (eg, sandy bridge) systems?. thanks. .mrg.
Re: What to do with base X11 for netbsd-9 ?
Hi Martin, On 5/29/19 9:12 AM, Martin Husemann wrote: I would like to get your feedback about the current state of the base X11, as there have been lots of threads about various issues and I have lost the overview of what works in -current and what does not. We*really* need to branch netbsd-9 very soon now, and it is unclear (at least to me) what should happen to the in-tree X11 version. - we have very obvious display bugs at first sight in xdm - self hosting builds on 4 GB amd64 machines are not really possible any more (due to LLVM runtime dependencies, which can not even be disabled at build time right now) - reports here (and on other lists) about display problems and success stories have no clear winner (but probably due to me losing track) So what is you story/opinion: is base X11 usable in -current? If not, what needs to be done or what hardware needs fixes? sorry to jump in late - I had "real work" distracting me to do test builds and also I had issues of building current since weeks. With a trick, I completed tools, kernel and whole distribution with X. First, the build was done on amd64 dual-core and I don't have more than 4GB of RAM. It takes now an extreme amount of time though. I start X from console (no xdm) and run windowmaker and see terrible artefacts: the background gets black on mouse operations, just opening the menu makes them jump (black blocks on the blue background) and even scrolling through the menus makes them repeatedly flicker, an incredible mess. Opening xterm and moving the window caused unrelated parts of the screen becoming black... However, once I did rebuild windowmaker, they disappeared! I assume thus some kind of binary incomaptibility? Maybe other too need some rebuild some packages? Some incompatibility was perhaps introduced compared to current of some months ago. Riccardo
Re: What to do with base X11 for netbsd-9 ?
Hi, On 5/29/19 2:27 PM, John D. Baker wrote: The functional issue is with the xf86-video-intel driver. It does not work on any of my amd64 systems using intel graphics devices. (It does work well on older i386 systems using real i82915 chips or ancient i82810e device). I don't know what the exact version of intel graphics I have, but it is not the "old" one with the real chip... it must be either the 4500 or what was shipped with Core processors. Several issues started going away when I recompiled pkgs! strange, isn't it? If you want I can post dmesg and see if we can compare chips. Riccardo
Re: What to do with base X11 for netbsd-9 ?
On Thu, May 30, 2019 at 07:22:08PM +0200, Joerg Sonnenberger wrote: > On Wed, May 29, 2019 at 09:12:42AM +0200, Martin Husemann wrote: > > - self hosting builds on 4 GB amd64 machines are not really possible > >any more (due to LLVM runtime dependencies, which can not even be > >disabled at build time right now) > > I'm pretty sure that statement is false by itself. At the very least, > you are adding "MKDEBUG=yes" implicitly. Yes, I am always building with MKDEBUG=yes and I haven't tried without. I suggested (to Maya, off list) some time ago to exclude the tools part of the LLVM build to be excluded from MKDEBUG (e.g. to require some extra MKLLVM_MAINTAINER_DEBUG or whatever we'd call it), but it is not clear to me how much build time and swap usage that would chop off. Martin
Re: What to do with base X11 for netbsd-9 ?
On Wed, May 29, 2019 at 09:12:42AM +0200, Martin Husemann wrote: > - self hosting builds on 4 GB amd64 machines are not really possible >any more (due to LLVM runtime dependencies, which can not even be >disabled at build time right now) I'm pretty sure that statement is false by itself. At the very least, you are adding "MKDEBUG=yes" implicitly. Joerg
Re: What to do with base X11 for netbsd-9 ?
jdba...@consolidated.net ("John D. Baker") writes:
>> Different display resolution?
>Seems strange that it could depend on that.
xdm does some guesswork on font metrics.
We are only talking about the damaged borders caused by the input
being placed a bit too low.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: What to do with base X11 for netbsd-9 ?
ci4...@gmail.com (Chavdar Ivanov) writes: >Well, I have the exact of similar problems on the same setup with xdm, >gdm, kdm and slim, so no, it doesn't appear to be local to xdm, but to >something common in all these login managers. Doubtful that there is a bug only affecting login managers :) xdm places the input data and the cursor one or two pixels too low, damaging the border while you type. Some people also report completely different artefacts like shaded rectangles that are not related to xdm but they notice these when xdm is started. That is probably a driver bug. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: What to do with base X11 for netbsd-9 ?
On Thu, 30 May 2019 06:18:45 - (UTC), mlel...@serpens.de (Michael
van Elst) wrote:
> jdba...@consolidated.net ("John D. Baker") writes:
> >OK, but I'm talking about xf86-video-intel, which is the driver this
> >machine uses even though it has never had any kind of DRM support.
> >So when running 'xdm', the i82810e is getting it right and the others
> >(other intel, radeon, nouveau) are not?
> Different display resolution?
Seems strange that it could depend on that.
The i82810e machine is driving a CRT display at 1600x1200x16
The i82G41 machine is driving a 1280x1024 LCD panel via DVI.
The i82Q45 machine is driving a CRT display capable of 1600x1200, but
can't seem to set any mode other than 1024x768.
The other i915drmkms and radeondrmkms machines are driving a 1024x768
LCD panel via VGA.
The one nouveau machine I've been able to test is driving a 1920x1200 LCD
panel via DVI.
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: What to do with base X11 for netbsd-9 ?
На 2019-05-30 в 12:56, Martin Husemann написа: > On Thu, May 30, 2019 at 12:25:42PM +0100, Chavdar Ivanov wrote: >>> Michael looked into it, and it seems to be code bugs (calculating the >>> edit field sizes and border coordinates). It is not just resource changes. >>> >>> This should be easy to fix and also (as it seems to be local to xdm itself) >> Well, I have the exact of similar problems on the same setup with xdm, >> gdm, kdm and slim, so no, it doesn't appear to be local to xdm, but to >> something common in all these login managers. > So that sounds like a different problem - is there a PR about it? I will have to revise the statement above - I haven't tried recently xdm and slim and went to rebuild and test them. On my setup xdm works without any problem now, there are no ill effects whatsoever. The same is with slim. The minor problems remain with gdm - short random horizontal streaks, sometimes staying, sometimes disappearing; with kdm I have some weird font rendering the first time I login into it, but subsequent logins appear fine. I will rebuild gdm and kdm just in case, but as far as I can see it, my system now is quite usable. > > Martin
Re: What to do with base X11 for netbsd-9 ?
On Thu, May 30, 2019 at 12:25:42PM +0100, Chavdar Ivanov wrote: > > Michael looked into it, and it seems to be code bugs (calculating the > > edit field sizes and border coordinates). It is not just resource changes. > > > > This should be easy to fix and also (as it seems to be local to xdm itself) > > Well, I have the exact of similar problems on the same setup with xdm, > gdm, kdm and slim, so no, it doesn't appear to be local to xdm, but to > something common in all these login managers. So that sounds like a different problem - is there a PR about it? Martin
Re: What to do with base X11 for netbsd-9 ?
On Thu, 30 May 2019 at 09:29, Martin Husemann wrote: > > On Wed, May 29, 2019 at 06:15:52PM -, Christos Zoulas wrote: > > >> - we have very obvious display bugs at first sight in xdm > > > > > >let's revert to the old xdm for now. this one should be easy. > > >can someone work on it please? > > > > Are those display bugs though? Or is it just that the right default > > properties are not there? If it is just a properties issue, we can > > fix it differently. > > Michael looked into it, and it seems to be code bugs (calculating the > edit field sizes and border coordinates). It is not just resource changes. > > This should be easy to fix and also (as it seems to be local to xdm itself) Well, I have the exact of similar problems on the same setup with xdm, gdm, kdm and slim, so no, it doesn't appear to be local to xdm, but to something common in all these login managers. > not be very important - but for me it is the first thing that a "typical" > (in my personal value of typical) user will see after properly setting > up a new NetBSD machine (or updating an existing installation). > > It certainly is no reason to delay the branch itself. > > Martin --
Re: What to do with base X11 for netbsd-9 ?
On Wed, May 29, 2019 at 06:15:52PM -, Christos Zoulas wrote: > >> - we have very obvious display bugs at first sight in xdm > > > >let's revert to the old xdm for now. this one should be easy. > >can someone work on it please? > > Are those display bugs though? Or is it just that the right default > properties are not there? If it is just a properties issue, we can > fix it differently. Michael looked into it, and it seems to be code bugs (calculating the edit field sizes and border coordinates). It is not just resource changes. This should be easy to fix and also (as it seems to be local to xdm itself) not be very important - but for me it is the first thing that a "typical" (in my personal value of typical) user will see after properly setting up a new NetBSD machine (or updating an existing installation). It certainly is no reason to delay the branch itself. Martin
Re: What to do with base X11 for netbsd-9 ?
jdba...@consolidated.net ("John D. Baker") writes:
>OK, but I'm talking about xf86-video-intel, which is the driver this
>machine uses even though it has never had any kind of DRM support.
>So when running 'xdm', the i82810e is getting it right and the others
>(other intel, radeon, nouveau) are not?
Different display resolution?
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: What to do with base X11 for netbsd-9 ?
On Thu, 30 May 2019, m...@netbsd.org wrote: > GPUs have special routines for 'put this image on top of another > surface', and they're used for fonts. > > xf86-video-vesa doesn't, it's doing things in an inefficient way in > software, but it probably allows for more checks about whether we're > still inside the surface boundaries. OK, but I'm talking about xf86-video-intel, which is the driver this machine uses even though it has never had any kind of DRM support. So when running 'xdm', the i82810e is getting it right and the others (other intel, radeon, nouveau) are not? -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: What to do with base X11 for netbsd-9 ?
GPUs have special routines for 'put this image on top of another surface', and they're used for fonts. xf86-video-vesa doesn't, it's doing things in an inefficient way in software, but it probably allows for more checks about whether we're still inside the surface boundaries.
Re: What to do with base X11 for netbsd-9 ?
On Wed, 29 May 2019 20:10:19 - (UTC), mlel...@serpens.de (Michael van Elst) wrote: > It's lousy code that computes the input fields geometry wrongly. An interesting data point noted here: http://mail-index.netbsd.org/current-users/2019/04/13/msg035573.html and more importantly here: http://mail-index.netbsd.org/netbsd-bugs/2019/04/15/msg061757.html is that an intel video device with no DRM support at all (neither KMS nor UMS) does not exhibit the glitching/bad field geometry. All the other devices I tried had some form of DRM (most KMS, except a VIA device which used "viadrmums" driver). I don't think I have any other non-DRM-supported video devices--all at least use the legacy UMS drm drivers in my custom kernels, but most of those don't have video console normally. Perhaps the problem is in the DRM subsystem (whether KMS or UMS)? -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: What to do with base X11 for netbsd-9 ?
On Wed, May 29, 2019 at 05:55:26PM -0500, John D. Baker wrote: > On Wed, 29 May 2019, m...@netbsd.org wrote: > > > what intel graphics do you have? > > what is failing with xf86-video-intel? > > See: > > http://mail-index.netbsd.org/current-users/2019/04/11/msg035551.html > http://mail-index.netbsd.org/current-users/2019/04/12/msg035561.html > http://mail-index.netbsd.org/current-users/2019/04/29/msg035698.html > > -- > |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X > |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD > | X No HTML/proprietary data in email. BSD just sits there and works! > |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645 Is your problem that your hardware is too old to be using SNA but it's still picked? This doesn't contain /var/log/Xorg.0.log.
Re: What to do with base X11 for netbsd-9 ?
On Wed, 29 May 2019, m...@netbsd.org wrote: > what intel graphics do you have? > what is failing with xf86-video-intel? See: http://mail-index.netbsd.org/current-users/2019/04/11/msg035551.html http://mail-index.netbsd.org/current-users/2019/04/12/msg035561.html http://mail-index.netbsd.org/current-users/2019/04/29/msg035698.html -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: What to do with base X11 for netbsd-9 ?
m...@eterna.com.au (matthew green) writes: >> >The functional issue is with the xf86-video-intel driver. It does not >> >work on any of my amd64 systems using intel graphics devices. (It does >> >work well on older i386 systems using real i82915 chips or ancient i82810e >> >device). >> >> It seems to work on my laptop (Sandy Bridge graphics). >for me it works for many things, but not true type fonts in some >terminal programs. >the canonical failure mode is simply typing into "mate-terminal", >and you get garbage in the typed text until you press return. I just tried with several terminals (not mate-terminal) and "Luxi Mono", seems to work as expected. xterm has a small problem with the Oblique variant because it exceeds the regular bounding box and is clipped, but I doubt that's a driver issue. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: What to do with base X11 for netbsd-9 ?
chris...@astron.com (Christos Zoulas) writes: >>let's revert to the old xdm for now. this one should be easy. >>can someone work on it please? >Are those display bugs though? Or is it just that the right default >properties are not there? If it is just a properties issue, we can >fix it differently. It's lousy code that computes the input fields geometry wrongly. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: What to do with base X11 for netbsd-9 ?
My two pennies... I use -current on an HP Envy 17 with what is reported as Intel 530 graphics. It also has an NVidia GeForce 950M chip, but this is not usable for now by NetBSD, although correctly identified. The new graphics driver together with the Mesa updates finally got me with a proper 3D-accellerated graphics and perfectly running in full screen video. I can run, e.g. six simultaneous copies of glmark2, it doesn't break sweat. The accellerated 3D works fine in epiphany as well, as I have mentioned in another email (but not in firefox 67.0). Hence, I wouldn't like global switch back to the old Intel driver. Modesetting works as well, but without any of the goodies mentioned above. I think I've had a single Xorg crash while testing 3D, but it was perhapsp too much. Earlier glmark2 used to crash on exit, not any more. The system has been very stable for me for the last few weeks. The only problem I have - as most of the rest have said - is with xdm, the apparently cosmetic nisdiplay of the username and password echo. There was a suggestion to bring back the old xdm; I don't know the difference, but I can tell that I have similar problems not only with xdm, but with gdm, kdm and slim as well. They all work, but show different types of screen damage (e.g. gdm - slowly disappearing short horisontal lines close to the bottom of the screen). The subsequent envirinments - mate, kde, gnome - all work OK, no screen distorsions. Previously I had weird looking wndows under xfce4 - the shadows appearing solid, long delays moving windows around - but these are now gone ( I start xfce4 from text mode with startxfce4 ). So for me the built-in Xorg is getting to a rather usable state now. There is a message about the two microcode files not being loaded (even if I have placed the latest versions in the relevant location, others have reported similarly ), but I am not aware if this makes any difference for the Intel driver. It would have been nice if we had a newer nouveau port and the GeForce card was supported, but this is not a showstopper for me ( even under Linux the Optimus configurations seldom work properly ). Chavdar On Wed, 29 May 2019 at 19:16, Christos Zoulas wrote: > > In article <26566.1559152...@splode.eterna.com.au>, > matthew green wrote: > >Martin Husemann writes: > >> Hey folks, > >> > >> I would like to get your feedback about the current state of the base X11, > >> as there have been lots of threads about various issues and I have lost > >> the overview of what works in -current and what does not. > >> > >> We *really* need to branch netbsd-9 very soon now, and it is unclear (at > >> least to me) what should happen to the in-tree X11 version. > >> > >> - we have very obvious display bugs at first sight in xdm > > > >let's revert to the old xdm for now. this one should be easy. > >can someone work on it please? > > Are those display bugs though? Or is it just that the right default > properties are not there? If it is just a properties issue, we can > fix it differently. > > >> - self hosting builds on 4 GB amd64 machines are not really possible > >>any more (due to LLVM runtime dependencies, which can not even be > >>disabled at build time right now) > > > >we should fix it to be disable-able. i don't think the default > >should change. [*] > > Yes, we should fix it to be disable-able and the default should > stay to build it. > > > > >> - reports here (and on other lists) about display problems and success > >>stories have no clear winner (but probably due to me losing track) > > > >i've not heard back about anyone using the now-re-addded old > >intel driver yet, but AFAICT, everyone either had success with > >dropping the old driver binary in place or using 'modesetting'. > > > >i was hoping to find time to bisect the intel driver tree from > >the 2014-snapshot to the top of tree to find where the display > >issues appeared, but perhaps we should switch back to the old > >driver for now until i or someone has fixed the new one.. > > My experience with the new driver has been better than that with > the old driver (fewer to none visual artifact issues). > > christos > --
re: What to do with base X11 for netbsd-9 ?
Jason Thorpe writes: > > > > On May 29, 2019, at 11:02 AM, matthew green wrote: > > > > i was hoping to find time to bisect the intel driver tree from > > the 2014-snapshot to the top of tree to find where the display > > issues appeared, but perhaps we should switch back to the old > > driver for now until i or someone has fixed the new one.. > > Do other operating systems have the same problems with the Intel driver? it's certainly the case that there are some linux issues with the current code, but i do not know if the problems are the same. (there are a few posts about it, but it's been a while since i read them. maya may remember more.) .mrg.
Re: What to do with base X11 for netbsd-9 ?
In article <26566.1559152...@splode.eterna.com.au>, matthew green wrote: >Martin Husemann writes: >> Hey folks, >> >> I would like to get your feedback about the current state of the base X11, >> as there have been lots of threads about various issues and I have lost >> the overview of what works in -current and what does not. >> >> We *really* need to branch netbsd-9 very soon now, and it is unclear (at >> least to me) what should happen to the in-tree X11 version. >> >> - we have very obvious display bugs at first sight in xdm > >let's revert to the old xdm for now. this one should be easy. >can someone work on it please? Are those display bugs though? Or is it just that the right default properties are not there? If it is just a properties issue, we can fix it differently. >> - self hosting builds on 4 GB amd64 machines are not really possible >>any more (due to LLVM runtime dependencies, which can not even be >>disabled at build time right now) > >we should fix it to be disable-able. i don't think the default >should change. [*] Yes, we should fix it to be disable-able and the default should stay to build it. > >> - reports here (and on other lists) about display problems and success >>stories have no clear winner (but probably due to me losing track) > >i've not heard back about anyone using the now-re-addded old >intel driver yet, but AFAICT, everyone either had success with >dropping the old driver binary in place or using 'modesetting'. > >i was hoping to find time to bisect the intel driver tree from >the 2014-snapshot to the top of tree to find where the display >issues appeared, but perhaps we should switch back to the old >driver for now until i or someone has fixed the new one.. My experience with the new driver has been better than that with the old driver (fewer to none visual artifact issues). christos
Re: What to do with base X11 for netbsd-9 ?
> On May 29, 2019, at 11:02 AM, matthew green wrote: > > i was hoping to find time to bisect the intel driver tree from > the 2014-snapshot to the top of tree to find where the display > issues appeared, but perhaps we should switch back to the old > driver for now until i or someone has fixed the new one.. Do other operating systems have the same problems with the Intel driver? -- thorpej
re: What to do with base X11 for netbsd-9 ?
> >The functional issue is with the xf86-video-intel driver. It does not > >work on any of my amd64 systems using intel graphics devices. (It does > >work well on older i386 systems using real i82915 chips or ancient i82810e > >device). > > It seems to work on my laptop (Sandy Bridge graphics). for me it works for many things, but not true type fonts in some terminal programs. the canonical failure mode is simply typing into "mate-terminal", and you get garbage in the typed text until you press return. the old (2014) driver does not have this problem. .mrg.
Re: What to do with base X11 for netbsd-9 ?
what intel graphics do you have? what is failing with xf86-video-intel?
re: What to do with base X11 for netbsd-9 ?
> * r600_dri.so (and other DRI drivers) being linked improperly. Missing > libxcb symbol errors when loading libGL with dlopen, as a lot of OpenGL > software seems inclined to do. I committed a workaround for this to SDL2 > the other day, as well as etlegacy. It's still a problem with software > that uses libepoxy. are there PRs about this? we should fix the base .. > * Certain programs that use OpenGL contexts can make the X server > segfault when they exit. Reproducable by compiling retroarch with > the x11+opengl options, starting and exiting it. one should be able to get a real core by either attaching gdb after X starts or turn off trapsignals - in the ServerFlags section of xorg.conf have this line: Option "NoTrapSignals" "true" then we can find the crash location and fix it.. thanks. .mrg.
Re: What to do with base X11 for netbsd-9 ?
> [*] i wonder if a hack to make to force a lower parallism for
> some subdirs would help these systems. eg:
>
> .MAKE.PARALLEL= ${MAKE_LLVM_JOBS:U${MAKE_JOBS}}
>
> and the (new) .MAKE.PARALLEL would set the -jN value for this
> sub-make, allowing other sub-makes to be run concurrently,
> but only N in llvm.
That sounds reasonable. Some random thoughts that I don't think deserve
to be taken entirely seriously.
I wonder if a simpler scheme would be good enough, which is that if
MAKE_HUGE_NO_PARALLEL is defined, use -j1 for things that use more than
typical resources.
What's unclear to me is how the changing of -j interacts when there
seems to be some attempt to parcel out the total jobs. I suppose the
llvm jobs could be counted as N, for -jN -- which perhaps represents
what's going on well.
Ideally, we would perhaps have a way to have a -J which is in terms of
MB of working set, instead of #jobs. ENOPATCH, I know.
re: What to do with base X11 for netbsd-9 ?
Martin Husemann writes:
> Hey folks,
>
> I would like to get your feedback about the current state of the base X11,
> as there have been lots of threads about various issues and I have lost
> the overview of what works in -current and what does not.
>
> We *really* need to branch netbsd-9 very soon now, and it is unclear (at
> least to me) what should happen to the in-tree X11 version.
>
> - we have very obvious display bugs at first sight in xdm
let's revert to the old xdm for now. this one should be easy.
can someone work on it please?
> - self hosting builds on 4 GB amd64 machines are not really possible
>any more (due to LLVM runtime dependencies, which can not even be
>disabled at build time right now)
we should fix it to be disable-able. i don't think the default
should change. [*]
> - reports here (and on other lists) about display problems and success
>stories have no clear winner (but probably due to me losing track)
i've not heard back about anyone using the now-re-addded old
intel driver yet, but AFAICT, everyone either had success with
dropping the old driver binary in place or using 'modesetting'.
i was hoping to find time to bisect the intel driver tree from
the 2014-snapshot to the top of tree to find where the display
issues appeared, but perhaps we should switch back to the old
driver for now until i or someone has fixed the new one..
.mrg.
[*] i wonder if a hack to make to force a lower parallism for
some subdirs would help these systems. eg:
.MAKE.PARALLEL= ${MAKE_LLVM_JOBS:U${MAKE_JOBS}}
and the (new) .MAKE.PARALLEL would set the -jN value for this
sub-make, allowing other sub-makes to be run concurrently,
but only N in llvm.
Re: What to do with base X11 for netbsd-9 ?
Paul Goyette wrote: >I am curious why we need to apparently build all of the LLVM stuff for a >release? If LLVM is needed as part of the build, it should be built as >host tools; I don't understand why we _also_ need to build LLVM for the >target machine. (And, if the answer to this is YES, we should probably >find a way to build-and-install a minimal subset, not the whole thing!) LLVM generates code that runs on the GPU, it is only used on the target machine. It is already fairly stripped down, only a couple of the code generation targets are built. I don't know if we could leave out X86 as well if doing a gcc build. It doesn't help that we build it twice for amd64, building with MKCOMPAT=no will be faster.
Re: What to do with base X11 for netbsd-9 ?
Martin Husemann wrote: >I would like to get your feedback about the current state of the base X11, >as there have been lots of threads about various issues and I have lost >the overview of what works in -current and what does not. >We *really* need to branch netbsd-9 very soon now, and it is unclear (at >least to me) what should happen to the in-tree X11 version. > - we have very obvious display bugs at first sight in xdm > - self hosting builds on 4 GB amd64 machines are not really possible > any more (due to LLVM runtime dependencies, which can not even be > disabled at build time right now) > - reports here (and on other lists) about display problems and success > stories have no clear winner (but probably due to me losing track) >So what is you story/opinion: is base X11 usable in -current? If not, >what needs to be done or what hardware needs fixes? I'm typing this using radeon on -current, don't see any problems but only have an old CEDAR GPU. Get errors on firefox startup of: libGL error: unable to load driver: r600_dri.so libGL error: driver pointer missing libGL error: failed to load driver: r600 libGL error: unable to load driver: swrast_dri.so libGL error: failed to load driver: swrast Intel - Only have an i915 machine, display itself seems fine but no HW acceleration for video playback. Wondering if the driver expects a different SW stack between the video player and itself. Video playback was fine with both the older driver and the intel.old one. NVidia - Only have an old laptop with an NV44. Seems to be using the nouveau driver. Video playback works but looks like it is SW only. Don't see any display problems, glxgears runs. I don't use xdm on any of these systems. I just start X11 as a normal user, did try starting it as root on my pinebook to verify a bug report and got a black desktop instead of the standard pattern. I did agree to try to update the radeon microcode in the tree but ran into a problem that there are two versions of some files, one named in uppercase the other lowercase, not tracked down yet how & why they differ.
Re: What to do with base X11 for netbsd-9 ?
> On May 29, 2019, at 5:36 AM, Paul Goyette wrote: > > I am curious why we need to apparently build all of the LLVM stuff for a > release? If LLVM is needed as part of the build, it should be built as > host tools; I don't understand why we _also_ need to build LLVM for the > target machine. (And, if the answer to this is YES, we should probably > find a way to build-and-install a minimal subset, not the whole thing!) LLVM is used at run-time in the graphics pipeline for some drivers. -- thorpej
Re: What to do with base X11 for netbsd-9 ?
On Wed, May 29, 2019 at 07:27:32AM -0500, John D. Baker wrote:
> The
> couple of times I've fired up 'mpv' it worked but seemed to complain
> about software rendering and dumped core on exit.
In my experience, mpv always dumps core when exiting, but it's a
problem in X.
When using modular X, the attached debugging patch that just adds some
printfs made the problem disappear (or at least hide). I don't
understand the root cause, nor have I tried porting the patch to native X.
Thomas
Index: distinfo
===
RCS file: /cvsroot/pkgsrc/graphics/MesaLib/distinfo,v
retrieving revision 1.120
diff -u -r1.120 distinfo
--- distinfo22 Mar 2017 20:22:31 - 1.120
+++ distinfo2 Jul 2017 22:04:38 -
@@ -6,7 +6,7 @@
Size (mesa-11.2.2.tar.xz) = 7860932 bytes
SHA1 (patch-configure) = 87f0f2e60f342c91b3aecab02d3a4d8940eadf0a
SHA1 (patch-include_GL_glxext.h) = 830902f2d38a8395cda682c059fc5223e1b0e89e
-SHA1 (patch-src_compiler_glsl_builtin__functions.cpp) =
1be4e67eda2105f375942c2991cf432e5d74e597
+SHA1 (patch-src_compiler_glsl_builtin__functions.cpp) =
8cb86cda4e25c9a79787f27f0556b1fa53a4e683
SHA1 (patch-src_egl_drivers_dri2_platform__drm.c) =
99b6dd6739c29551ae2c885eabd7babd159fc3e5
SHA1 (patch-src_egl_drivers_dri2_platform__x11.c) =
04b6ef8e755f226fbe3e6f2bea6c9e2a56a783ca
SHA1 (patch-src_egl_main_eglglobals.c) =
2d81ae27f09162d23bc684456cc5fef48c042652
Index: patches/patch-src_compiler_glsl_builtin__functions.cpp
===
RCS file:
/cvsroot/pkgsrc/graphics/MesaLib/patches/patch-src_compiler_glsl_builtin__functions.cpp,v
retrieving revision 1.2
diff -u -r1.2 patch-src_compiler_glsl_builtin__functions.cpp
--- patches/patch-src_compiler_glsl_builtin__functions.cpp 15 Jan 2017
00:14:21 - 1.2
+++ patches/patch-src_compiler_glsl_builtin__functions.cpp 2 Jul 2017
22:04:38 -
@@ -4,11 +4,28 @@
--- src/compiler/glsl/builtin_functions.cpp.orig 2016-05-09
12:51:42.0 +
+++ src/compiler/glsl/builtin_functions.cpp
-@@ -853,6 +853,7 @@ builtin_builder::builtin_builder()
+@@ -852,7 +852,10 @@ builtin_builder::builtin_builder()
+
builtin_builder::~builtin_builder()
{
++printf("builtin_builder::~builtin_builder in\n");
ralloc_free(mem_ctx);
+ mem_ctx = NULL;
++printf("builtin_builder::~builtin_builder out\n");
}
ir_function_signature *
+@@ -896,11 +899,13 @@ builtin_builder::initialize()
+ void
+ builtin_builder::release()
+ {
++printf("builtin_builder::release in\n");
+ralloc_free(mem_ctx);
+mem_ctx = NULL;
+
+ralloc_free(shader);
+shader = NULL;
++printf("builtin_builder::release out\n");
+ }
+
+ void
Re: What to do with base X11 for netbsd-9 ?
jdba...@consolidated.net ("John D. Baker") writes:
>The glitches in 'xdm' input fields are annoying. While only cosmetic,
>they may have a negative impact on external perceptions of NetBSD.
Yes, ancient code, that wasn't far from perfect, got "improved".
But it should be easy to fix.
>The functional issue is with the xf86-video-intel driver. It does not
>work on any of my amd64 systems using intel graphics devices. (It does
>work well on older i386 systems using real i82915 chips or ancient i82810e
>device).
It seems to work on my laptop (Sandy Bridge graphics).
>In the meantime, the "modesetting" driver seems to be adequate, but I
>have not extensively tested video yet, other than firefox/youtube. The
>couple of times I've fired up 'mpv' it worked but seemed to complain
>about software rendering and dumped core on exit.
Yes, the coredump is annoying. Probably some atexit() issue again.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: What to do with base X11 for netbsd-9 ?
Well, my problems are not with X but with in-kernel nouveau driver. I have noted my issues several times in the past: * GTX 1050-Ti not supported, so I have to use vga kernel driver. * Shutting down xdm(8) normally results in a totally black screen with no control, and no ability even for blind typing. * Therefore, a system shutdown or reboot requires manually using ``kill -9'' on xdm (from the console), followed by shutdown(9). * Once I've killed xdm, I cannot restart it - I _must_ reboot! * Attempts to use the vesa driver (rather than vga) have been unsuccessful. I have a (rather "sub-optimal") workaround for my situation, so it's not critical, and I would not use my issues as a reason for delaying the up-coming branch of NetBSD-9. I am curious why we need to apparently build all of the LLVM stuff for a release? If LLVM is needed as part of the build, it should be built as host tools; I don't understand why we _also_ need to build LLVM for the target machine. (And, if the answer to this is YES, we should probably find a way to build-and-install a minimal subset, not the whole thing!) On Wed, 29 May 2019, Martin Husemann wrote: Hey folks, I would like to get your feedback about the current state of the base X11, as there have been lots of threads about various issues and I have lost the overview of what works in -current and what does not. We *really* need to branch netbsd-9 very soon now, and it is unclear (at least to me) what should happen to the in-tree X11 version. - we have very obvious display bugs at first sight in xdm - self hosting builds on 4 GB amd64 machines are not really possible any more (due to LLVM runtime dependencies, which can not even be disabled at build time right now) - reports here (and on other lists) about display problems and success stories have no clear winner (but probably due to me losing track) So what is you story/opinion: is base X11 usable in -current? If not, what needs to be done or what hardware needs fixes? Martin !DSPAM:5cee313a49191121140670! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: What to do with base X11 for netbsd-9 ?
The glitches in 'xdm' input fields are annoying. While only cosmetic, they may have a negative impact on external perceptions of NetBSD. The functional issue is with the xf86-video-intel driver. It does not work on any of my amd64 systems using intel graphics devices. (It does work well on older i386 systems using real i82915 chips or ancient i82810e device). I have not yet had a chance to try the re-imported older (2014?) video driver for intel. In the meantime, the "modesetting" driver seems to be adequate, but I have not extensively tested video yet, other than firefox/youtube. The couple of times I've fired up 'mpv' it worked but seemed to complain about software rendering and dumped core on exit. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: What to do with base X11 for netbsd-9 ?
On 29.05.2019 11:41, Kamil Rytarowski wrote: > On 29.05.2019 09:12, Martin Husemann wrote: >> Hey folks, >> >> I would like to get your feedback about the current state of the base X11, >> as there have been lots of threads about various issues and I have lost >> the overview of what works in -current and what does not. >> >> We *really* need to branch netbsd-9 very soon now, and it is unclear (at >> least to me) what should happen to the in-tree X11 version. >> >> - we have very obvious display bugs at first sight in xdm >> - self hosting builds on 4 GB amd64 machines are not really possible >>any more (due to LLVM runtime dependencies, which can not even be >>disabled at build time right now) >> - reports here (and on other lists) about display problems and success >>stories have no clear winner (but probably due to me losing track) >> >> So what is you story/opinion: is base X11 usable in -current? If not, >> what needs to be done or what hardware needs fixes? >> >> Martin >> > > Intel i915drmkms is broken for me on 2 laptops. The newer Intel driver > works better than the older one. I'm busy waiting for audio to stabilize > before another upgrade, retrying and debugging if needed. > I will try to upgrade now and report back.. but it will take a while (rust build, firefox build...). signature.asc Description: OpenPGP digital signature
Re: What to do with base X11 for netbsd-9 ?
On Wed, May 29, 2019 at 09:12:42AM +0200, Martin Husemann wrote: > So what is you story/opinion: is base X11 usable in -current? If not, > what needs to be done or what hardware needs fixes? Mostly, yeah. It was very broken in 8.0, and MesaLib and video-intel updates mean I no longer need to use modular xorg with my Kaby Lake laptop. My radeon destop runs well too. Recent changes improved the intel tearing situation. I'm reasonably happy. ... but I have two problems currently, with ugly workarounds in pkgsrc (which don't work for everything). Neither occurs when using modular xorg, and seem to be regressions: * r600_dri.so (and other DRI drivers) being linked improperly. Missing libxcb symbol errors when loading libGL with dlopen, as a lot of OpenGL software seems inclined to do. I committed a workaround for this to SDL2 the other day, as well as etlegacy. It's still a problem with software that uses libepoxy. * Certain programs that use OpenGL contexts can make the X server segfault when they exit. Reproducable by compiling retroarch with the x11+opengl options, starting and exiting it. maya has been helping investigate both, but we're stalled right now.
Re: What to do with base X11 for netbsd-9 ?
On 29.05.2019 09:12, Martin Husemann wrote: > Hey folks, > > I would like to get your feedback about the current state of the base X11, > as there have been lots of threads about various issues and I have lost > the overview of what works in -current and what does not. > > We *really* need to branch netbsd-9 very soon now, and it is unclear (at > least to me) what should happen to the in-tree X11 version. > > - we have very obvious display bugs at first sight in xdm > - self hosting builds on 4 GB amd64 machines are not really possible >any more (due to LLVM runtime dependencies, which can not even be >disabled at build time right now) > - reports here (and on other lists) about display problems and success >stories have no clear winner (but probably due to me losing track) > > So what is you story/opinion: is base X11 usable in -current? If not, > what needs to be done or what hardware needs fixes? > > Martin > Intel i915drmkms is broken for me on 2 laptops. The newer Intel driver works better than the older one. I'm busy waiting for audio to stabilize before another upgrade, retrying and debugging if needed. signature.asc Description: OpenPGP digital signature
