On Tue, 30 Apr 2019, Ron Georgia wrote:
> When I switched to using modesetting the tearing issue went away;
> however the display was a little grainy and there was a lot of "lag"
> in the video when doing things like moving a window (like when I used
> to use Window 3.1.1 on my 286 6MHz beast of a
All,
When I switched to using modesetting the tearing issue went away; however the
display was a little grainy and there was a lot of "lag" in the video when
doing things like moving a window (like when I used to use Window 3.1.1 on my
286 6MHz beast of a machine). I changed the driver to intel
На 2019-04-29 в 18:34, John D. Baker написа:
> I managed to fire up another machine w/intel graphics I have. It uses:
>
> [...]
> i915drmkms0 at pci0 dev 2 function 0: Intel 82946GZ Integrated Graphics
> Device (rev. 0x02)
> [...]
> kern info: [drm] Memory usable by graphics device = 512M
> ker
I managed to fire up another machine w/intel graphics I have. It uses:
[...]
i915drmkms0 at pci0 dev 2 function 0: Intel 82946GZ Integrated Graphics Device
(rev. 0x02)
[...]
kern info: [drm] Memory usable by graphics device = 512M
kern info: [drm] Supports vblank timestamp caching Rev 2 (21.10.2
On Sat, 13 Apr 2019, John D. Baker wrote:
> I suppose as an outlier data point, the intel driver works fine on an
> ancient i82810e-based system with no DRM/KMS nor UMS at all.
A machine with a real i82915 device works fine without any tweaks
required, albeit I am not sure now if I updated this m
While wrestling with another problem that my custom kernel has that
GENERIC doesn't, I double-checked the Xorg/intel behavior while running
GENERIC. The behavior is the same: the intel driver with "TearFree" on
with or without "AccelMethod" "SNA" is only marginally improved but still
doesn't draw
I suppose as an outlier data point, the intel driver works fine on an
ancient i82810e-based system with no DRM/KMS nor UMS at all.
The machine does need an "xorg.conf", but only to define the limits of
the CRT monitor--no "Device" section. I did have to tweak the "Display"
subsection to keep it f
I think it's the kernel too. I have a reduced way of reproducing it.
env LIBGL_ALWAYS_SOFTWARE=1 glmark2 (from pkgsrc) will be visibly
corrupt.
env LIBGL_ALWAYS_SOFTWARE=1 ktruss -i glmark2 > /dev/null
or a second glmark2 instance
seemed to make it go away.
I think this difference means it might
On both of the intel-graphics machines I've tried so far:
i915drmkms0 at pci0 dev 2 function 0: Intel 82G41 Integrated Graphics Device (re
v. 0x03)
Intel product 2e33 (miscellaneous display, revision 0x03) at pci0 dev 2 function
1 not configured
i915drmkms0 at pci0 dev 2 function 0: Intel 82Q45
With these two settings now kdm, xdm and slim work as expected;
previously the username and the password echo did not show properly.
Now my Intel graphics works rather well. I get hangs only when I run
some of the xscreensaver demos in full screen mode, rendering the
mouse/keyboard unresponsive - b
Update:
Using "modesetting" did clear up the issue.
Keeping the Driver as "intel" and setting "TearFree" to "true" with
"AccelMethod" set to "sna" also worked.
Not sure how this email group looks on adding links to emails. I found some
info on TearFree and sna on askubuntu and the Archlinux wiki
I don't think this is related to xf86. I started seeing these issues
when upgrading my kernel to the latest version while keeping all the
userland as is. So I assume it is related to an updated Intel kernel
driver.
I haven't tried but perhaps the "NoTear" option to the Xorg intel
driver would help
On Thu, Apr 11, 2019 at 11:01:52PM -0500, John D. Baker wrote:
> On the two intel-graphics machines I've tried now, I have the same
> problem I originally mentioned in:
>
> http://mail-index.netbsd.org/current-users/2019/04/11/msg035551.html
Just to make sure it is clear: the xdm glitches are
On Thu, 11 Apr 2019, Chavdar Ivanov wrote:
> Please don't be so quick reverting the Intel driver. With today's
> build my laptop is working very well, I have no visible effects,
> glmark2 executes as expected with the exception of the crash upon
> exit, Kde4 was previously crashing on testing the
Please don't be so quick reverting the Intel driver. With today's build my
laptop is working very well, I have no visible effects, glmark2 executes as
expected with the exception of the crash upon exit, Kde4 was previously
crashing on testing the gl capability, now everything works. Great work, in
i am fairly sure the new display glitches you are seeing are
related to the newer xf86-video-intel driver.
can people who are seeing issues not related to GL/Mesa try
forcing the "modesetting" driver instead? see if that makes
things go away? i am probably going to revert the driver in
-current
I have on occasion similar behaviour on my HP Envy laptop using the
530 graphics, it is rather weird. I also get the messages about not
being able to load the two microcode files, even if I have placed them
in the right location.
On Thu, 11 Apr 2019 at 21:31, Ron Georgia wrote:
>
> My monitor is
17 matches
Mail list logo
