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 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
>
Updating src tree:
P src/external/gpl3/gdb/dist/gdb/aarch64-nbsd-nat.c
P src/external/gpl3/gdb/dist/gdb/alpha-bsd-nat.c
P src/external/gpl3/gdb/dist/gdb/arm-nbsd-nat.c
P src/external/gpl3/gdb/dist/gdb/bsd-kvm.c
P src/external/gpl3/gdb/dist/gdb/configure.nat
P
Hi,
I am forwarding my email regarding my own old PR/43309 to
current-users, possibly it will have better visibility here. I wrote a
small patch which should fix:
* VX800 IDE will set correct UDMA mode. (VX855 should too, but can't test)
* If RAID mode is selected in BIOS (in my board), disks
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
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
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,
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
> 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.
vezh...@gmail.com (Andrius V) writes:
>current-users, possibly it will have better visibility here. I wrote a
>small patch which should fix:
>* VX800 IDE will set correct UDMA mode. (VX855 should too, but can't test)
That shouldn't be a problem to apply.
>* If RAID mode is selected in BIOS
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
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
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
> >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?
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
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
> [*] 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
> * 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
>
> 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
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
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
Hi,
with sources updated an hour or so ago I get:
..
/home/sysbuild/amd64/tools/bin/nbmakefs -M 1475346432 -m 1475346432
-B 1234 -F
work.spec -N w
ork/etc
-o bsize=16384,fsize=2048,density=8192
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
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
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
>
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
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 2:57 PM Michael van Elst wrote:
>
> vezh...@gmail.com (Andrius V) writes:
>
> >current-users, possibly it will have better visibility here. I wrote a
> >small patch which should fix:
> >* VX800 IDE will set correct UDMA mode. (VX855 should too, but can't test)
>
>
> That
30 matches
Mail list logo
