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]
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
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
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
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
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
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
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
> 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
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
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
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
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.
>
>
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 ?
--
--
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
* 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)
>
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.
>
>
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
> 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.
>
>
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.
* 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
> >>
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.
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.
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
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
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
На 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
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
> 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
> - 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
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
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
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
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.
--
--
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 :)
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
На 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
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
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?
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
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
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
>
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.
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:
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
>
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
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
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
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
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
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
> 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
> >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).
what intel graphics do you have?
what is failing with xf86-video-intel?
> * 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
>
> [*] 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
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
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,
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
> 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.
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
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
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
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
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
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
67 matches
Mail list logo
