What does this mean:
[ 626.850292] nouveau E[ PFIFO][:01:00.0] DMA_PUSHER - ch 2 [X[2059]]
get 0x0020008e60 put 0x0020008e80 ib_get 0x0093 ib_put 0x00a3 state
0x80004861 (err: INVALID_CMD) push 0x00406040
[ 659.132581] nouveau E[ PFIFO][:01:00.0] DMA_PUSHER - ch 2
Intermittent crashing X.
I downgraded to xorg-1.13.4 hoping it would be stable.
I have 2 monitors, 1920x1200 and 1920x1080
Things seem stable if I don't connect the second monitor.
This is in my /var/log/kdm.log:
(EE) [mi] EQ overflow continuing. 1000 events have been dropped.
(EE) [mi] No
Performance level selection (also known as reclocking) is not supported yet.
It's not supported but does it work in some cases.
[0.00] Command line: root=/dev/sdc1 rootfstype=ext4 raid=noautodetect
ro nouveau.pstate=1
[0.00] Kernel command line: root=/dev/sdc1 rootfstype=ext4
I have a video card with 2 outputs.
I don't usually have a monitor on the second output (HDMI).
I have to reboot if want to use a second monitor.
Is there a way to force lubuntu to rescan for the second monitor.
[ 1.507056] nouveau [ DEVICE][:01:00.0] Chipset: GK107 (NVE7)
[ 1.507057]
I have a NVE7 (GK107).
How do I see the current memory/CPU speed?
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On 2017-06-19 01:18 PM, Ilia Mirkin wrote:
> cat /sys/kernel/debug/dri/0/pstate
>
> AC (or DC) line shows the current state.
>
> On Mon, Jun 19, 2017 at 1:00 PM, James <bjloc...@lockie.ca> wrote:
>> I have a NVE7 (GK107).
>> How do I see the current memory/CPU spe
On 2017-06-19 01:38 PM, Ilia Mirkin wrote:
> On Mon, Jun 19, 2017 at 1:32 PM, James <bjloc...@lockie.ca> wrote:
>> On 2017-06-19 01:18 PM, Ilia Mirkin wrote:
>>> cat /sys/kernel/debug/dri/0/pstate
>>>
>>> AC (or DC) line shows the current state.
>
I am playing videos from my lubuntu computer to my tv through the hdmi
interface on my video card.
It mostly works.
Some sound doesn't and I think it is related to the audio code.
A52 Audio (aka AC3) (a52) works.
It seems MPEG AAC Audio (mp4a) doesn't work.
I checked a video that used to work and
On 2018-05-01 06:00 PM, Ilia Mirkin wrote:
> What GPU do you have? For video acceleration (i.e. va-api and vdpau),
> did you install the necessary firmware?
>
> On Tue, May 1, 2018 at 5:53 PM, James <bjloc...@lockie.ca> wrote:
>> I am playing videos from my lubuntu c
It turned out to be a simple fix.
I set the "Dolby Surround" option in vlc to on instead of auto.
Thanks for you help.
On 2018-05-01 06:19 PM, Ilia Mirkin wrote:
> On Tue, May 1, 2018 at 6:16 PM, James <bjloc...@lockie.ca> wrote:
>> On 2018-05-01 06:00 PM, Ilia Mirkin
On 2018-12-09 12:41 a.m., Ilia Mirkin wrote:
On Sun, Dec 9, 2018 at 12:24 AM James wrote:
# dmesg | grep -i nouveau
[2.171473] fb: switching to nouveaufb from VESA VGA
[2.171595] nouveau :01:00.0: NVIDIA GP107 (137000a1)
[2.286501] nouveau :01:00.0: bios: version
https://nouveau.freedesktop.org/wiki/CodeNames/
If you're running a recent version nouveau, you can find your chipset by doing
dmesg | grep -i chipset. This will always be correct, whereas the lists below
are approximate.
# dmesg | grep -i chipset
#
Not true anymore I guess.
What is the
I got 1920x1200@59.95Hz via DVI and 3840x2160@60.00Hz via HDMI at the
same time with the proprietary nvidia driver.
I get flickering on the 1920x1200@59.95 with the nouveau driver (it
doesn't flicker if I lower it to 1920x1080@59.96).
Any idea why?
proprietary:
$ xrandr
Screen 0: minimum 8 x
I have monitor connected by DVI and a 4K tv connected by HDMI.
I have a Gigabyte GeForce 1050 OC 2G video card.
The firmware takes 15 seconds to load (systemd-analyze) so I tried the
Ultra Fast Boot (UEFI) option in the BIOS.
With Ultra Fast Boot the firmware loads in less than 5 seconds.
All
On 2019-08-18 11:27 a.m., Ondrej Zary wrote:
On Saturday 17 August 2019 14:50:33 Alex Dewar wrote:
Hi all,
I'm getting frequent system crashes (every few hours or so) and it seems
that the nouveau driver is causing the issue (dmesg output below). I see it
with both v5.2.8 and the v4.19 LTS
I got this in dmesg.
I reconnected it and it works fine.
What caused that?
[ 253.203797] nouveau :07:00.0: HDMI-A-1: EDID is invalid:
[ 253.203801] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 253.203802] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[
Do you know why xrandr rounds up to "3840x2160 59.97" but the
lubuntu GUI says "3840x2160 59.9685"?
I thought it might be the TV only does 30Hz or 60Hz but it does
fractional rates at lower resolutions.
I don't know.
Maybe it is the colour depth.
Why is my first monitor 1920x1200 for
I was going to buy a new cable and I came across this description:
>Category 2 Certified HDMI wire supports resolutions up to 4Kx2K (UHD)
@30 Hz
https://www.cnet.com/how-to/what-is-hdmi-2-0b/
HDMI versions compared
HDMI VersionMax Resolution Max 4K Frame rate HDCP 2.2HDR
On 2019-08-06 12:32 p.m., Ilia Mirkin wrote:
Hi James,
I semi-recently added support for HDMI 2.0 (in 4.20+, so you're good),
which is why you got 60Hz in the first place. In order for the high
rates to work, something called "scrambling" must be enabled. This is
done by 2-party
I have a Gigabyte GeForce 1050 connected by DVI to a monitor (1920x1200
resolution @ 59.9502 Hz) and a TV via HDMI (3840x2160 @30 Hz).
The problem is the TV used to work at 59.9685 Hz but then it started
showing "No signal" on the TV.
I was changing settings trying to get it to work again and I
I think I may have updated the tv firmware between when it worked and
when it didn't.
I wonder it it has to do with bit depth.
I use lubuntu and it doesn't let me pick the bit depth so I don't know
what it using.
___
Nouveau mailing list
More generic approach below - it should work for all drm drivers.
Unfortunately vga16fb handoff has 2 other issues:
- It can be compiled as module, so it can be loaded after KMS driver (and
nothing prevents it right now)
- vga16fb registration error path is iounmapping memory which was not
view
it as the non-glitchy graphic model going forward.
Thanks,
-James
So i do not see what you would consider rocket science about this ?
Cheers,
Jérôme
(3) Allow user space to attach an explicit fence to dma-buf when exporting to
another driver that uses implicit sync
ers).
-ilia
On Thu, Oct 8, 2015 at 4:21 PM, James Lehman <ja...@akrobiz.com> wrote:
Hello. I hope this is in the right place.
I just built a new machine and installed Xubuntu and I'm still figuring
things out.
I'm interested in working with The Linux Frame Buffer.
Many years ago, I started
frame buffer is 640x480, 4 bit color. When I try fbset to change
anything, it doesn't work.
I have not even bothered to try my code so see of any of it can actually
work in the frame buffers I get.
Still scratching my head
Thank you for your time.
James
code to plot pixels.
Uh. I hate to ask this of the nouveau development team, but.
Is there any way to use the nVidia proprietary driver to get a 4K Linux
Frame Buffer?
Thanks again.
James.
On 10/08/2015 05:22 PM, Ilia Mirkin wrote:
HDMI with nouveau is limited to 165mhz unfortunately
[Posting again. The mailing list doesn't like HTML links.]
Hello,
As I reported in this(*) bug, the Nouveau ZaphodHeads option (separate
X-displays for the two heads of a single GPU)
stopped working on my GeForce 7600 GT (NV4B/G73) when I upgraded from Fedora 23
to 25. I'm really keen on
Hello,
As I reported in this
bug, the Nouveau ZaphodHeads option (separate X-displays for the
two heads of a single GPU) stopped working on my GeForce 7600 GT
(NV4B/G73) when I upgraded from Fedora 23 to 25. I'm really keen
on getting it back, because
se propose something
> else
> :-)
The interpretation document also says this:
ontributions submitted for the kernel should use appropriate
language. Content that already exists predating the Code of Conduct
will not be addressed now as a violation.
So that definitely means ther
On Fri, 2018-11-30 at 13:54 -0800, Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 01:48:08PM -0800, David Miller wrote:
> > From: Jarkko Sakkinen
> > Date: Fri, 30 Nov 2018 13:44:05 -0800
> >
> > > On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote:
to the point where it's effectively a new CoC has been
the source of much debate and recrimination over the last few months
... you can read it in the ksummit-discuss archives, but I really think
we don't want to reopen that can of worms.
James
__
On Fri, 2018-11-30 at 13:44 -0800, Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote:
> > No because use of what some people consider to be bad language
> > isn't necessarily abusive, offensive or degrading. Our most
> > heavily
precisely because
there was a lot of push back on interpretation problems and ambiguities
with the original CoC and it specifically covers this case (and a lot
of others).
James
> After this discussion, I can say that I understand it less than
> before.
>
> /Jarkko
>
by booting with nouveau.hdmimhz=340.
Cheers,
-ilia
On Tue, Aug 6, 2019 at 1:15 PM James wrote:
I was going to buy a new cable and I came across this description:
Category 2 Certified HDMI wire supports resolutions up to 4Kx2K (UHD)
@30 Hz
https://www.cnet.com/how-to/what-is-hdmi-2-0b/
HDMI
On 12/11/19 1:13 PM, Ilia Mirkin wrote:
On Wed, Dec 11, 2019 at 4:04 PM James Jones wrote:
Allow setting the block layout of a nouveau FB
object using DRM format modifiers. When
specified, the format modifier block layout and
kind overrides the GEM buffer's implicit layout
and kind
-static
to fix the logic.
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index f8015e0318d7..1b62ccc57aef 100644
--- a/drivers
r, because that will be a rather invasive
change to nouveau and 0x00 still works fine in
practice on Turing hardware, addressing this new
behavior is deferred.
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/include/nvif/if0008.h| 2 +-
drivers/gpu/drm/nouveau/include/nvif/mmu.h | 4 ++-
Make sure framebuffer dimensions and tiling
parameters will not result in accesses beyond the
end of the GEM buffer they are bound to.
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/nouveau_display.c | 93 +++
1 file changed, 93 insertions(+)
diff --git a/drivers
On 12/12/19 6:51 PM, James Jones wrote:
On 12/11/19 1:13 PM, Ilia Mirkin wrote:
On Wed, Dec 11, 2019 at 4:04 PM James Jones wrote:
Allow setting the block layout of a nouveau FB
object using DRM format modifiers. When
specified, the format modifier block layout and
kind overrides the GEM
.
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/dispnv50/base507c.c | 7 +--
drivers/gpu/drm/nouveau/dispnv50/disp.c | 59 +
drivers/gpu/drm/nouveau/dispnv50/disp.h | 4 ++
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 27 +-
drivers/gpu/drm/nouveau/dispnv50
hardware.
v2: Used Tesla family instead of NV50 chipset compare
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 8 +--
drivers/gpu/drm/nouveau/nouveau_display.c | 65 ++-
drivers/gpu/drm/nouveau/nouveau_display.h | 2 +
3 files changed, 69
, and left as-is for consistency with existing code.
James Jones (3):
drm/nouveau: Add format mod prop to base/ovly/nvdisp
drm/nouveau: Check framebuffer size against bo
drm/nouveau: Support NVIDIA format modifiers
drivers/gpu/drm/nouveau/dispnv50/base507c.c | 7 +-
drivers/gpu/drm/nouveau/dispn
v3:
- Added additional bit to compression field to
support Tesla (NV5x,G8x,G9x,GT1xx,GT2xx) class
chips.
Signed-off-by: James Jones
---
include/uapi/drm/drm_fourcc.h | 122 +++---
1 file changed, 114 insertions(+), 8 deletions(-)
diff --git a/include/uapi/drm/d
Make sure framebuffer dimensions and tiling
parameters will not result in accesses beyond the
end of the GEM buffer they are bound to.
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/nouveau_display.c | 93 +++
1 file changed, 93 insertions(+)
diff --git a/drivers
hardware.
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 8 +--
drivers/gpu/drm/nouveau/nouveau_display.c | 65 ++-
drivers/gpu/drm/nouveau/nouveau_display.h | 2 +
3 files changed, 69 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm
Block
Linear DRM format mod" patch submitted to dri-devel.
Signed-off-by: James Jones
---
drivers/gpu/drm/tegra/dc.c | 10 ++
drivers/gpu/drm/tegra/fb.c | 14 +++---
drivers/gpu/drm/tegra/hub.c | 10 ++
3 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/d
.
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/dispnv50/base507c.c | 7 +--
drivers/gpu/drm/nouveau/dispnv50/disp.c | 59 +
drivers/gpu/drm/nouveau/dispnv50/disp.h | 4 ++
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 27 +-
drivers/gpu/drm/nouveau/dispnv50
Please ignore the tegra diff on the bottom of this. I never fail to
find a way to mess up git-send-email.
-James
On 12/11/19 12:59 PM, James Jones wrote:
This series modifies the NV5x+ nouveau display backends to advertise
appropriate format modifiers on their display planes in atomic mode
nto
nouveau userspace drivers with modifiers in Mesa.
Hence it is assumed the prior modifiers were not
intended for use on desktop GPUs, and as a
corrolary, were not intended to support sharing
block linear buffers across two different NVIDIA
GPUs.
v2:
- Added canonicalize helper function
Signed-off
On 10/15/19 8:42 AM, Daniel Vetter wrote:
On Tue, Oct 15, 2019 at 5:14 PM James Jones wrote:
On 10/15/19 7:19 AM, Daniel Vetter wrote:
On Mon, Oct 14, 2019 at 03:13:21PM -0700, James Jones wrote:
Builds upon the existing NVIDIA 16Bx2 block linear
format modifiers by adding more "f
On 10/15/19 7:19 AM, Daniel Vetter wrote:
On Mon, Oct 14, 2019 at 03:13:21PM -0700, James Jones wrote:
Builds upon the existing NVIDIA 16Bx2 block linear
format modifiers by adding more "fields" to the
existing parameterized
DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK format modifier
macro
nto
nouveau userspace drivers with modifiers in Mesa.
Hence it is assumed the prior modifiers were not
intended for use on desktop GPUs, and as a
corrolary, were not intended to support sharing
block linear buffers across two different NVIDIA
GPUs.
Signed-off-by: James Jones
---
inclu
Beyond general review, I'm looking for feedback on a few things
specifically here:
-Is the level of backwards compatibility described here sufficient?
Technically I can make the user space drivers support the old
modifiers too, but that would mean the layout they specify would
morph based on
ed against nouveau_framebuffer cleanup
James Jones (3):
drm/nouveau: Add format mod prop to base/ovly/nvdisp
drm/nouveau: Check framebuffer size against bo
drm/nouveau: Support NVIDIA format modifiers
drivers/gpu/drm/nouveau/dispnv50/base507c.c | 7 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c
Make sure framebuffer dimensions and tiling
parameters will not result in accesses beyond the
end of the GEM buffer they are bound to.
v3: Return EINVAL when creating FB against BO with
unsupported tiling
v5: Resolved against nouveau_framebuffer cleanup
Signed-off-by: James Jones
display hardware.
v2: Used Tesla family instead of NV50 chipset compare
v4: Do not cache kind, tile_mode in nouveau_framebuffer
v5: Resolved against nouveau_framebuffer cleanup
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 20 +++--
drivers/gpu/drm/nouveau
.
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/dispnv50/base507c.c | 7 +--
drivers/gpu/drm/nouveau/dispnv50/disp.c | 59 +
drivers/gpu/drm/nouveau/dispnv50/disp.h | 4 ++
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 27 +-
drivers/gpu/drm/nouveau/dispnv50
ned-off-by: James Jones
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
index 4a67a656e007..68c0dc2dc2d3 100644
--- a/drivers/gpu/drm/nouveau/dispn
On 2/10/20 12:25 AM, Thomas Zimmermann wrote:
Hi
Am 10.02.20 um 09:20 schrieb Ben Skeggs:
On Sat, 8 Feb 2020 at 07:10, James Jones wrote:
I've sent out a v4 version of the format modifier patches which avoid
caching values in the nouveau_framebuffer struct. It will have a few
trivial
On 1/6/20 3:27 PM, Ben Skeggs wrote:
On Tue, 7 Jan 2020 at 05:17, James Jones wrote:
On 1/5/20 5:30 PM, Ben Skeggs wrote:
On Tue, 17 Dec 2019 at 10:44, James Jones wrote:
This series modifies the NV5x+ nouveau display backends to advertise
appropriate format modifiers on their display
hardware.
v2: Used Tesla family instead of NV50 chipset compare
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 8 +--
drivers/gpu/drm/nouveau/nouveau_display.c | 65 ++-
drivers/gpu/drm/nouveau/nouveau_display.h | 2 +
3 files changed, 69
Make sure framebuffer dimensions and tiling
parameters will not result in accesses beyond the
end of the GEM buffer they are bound to.
v3: Return EINVAL when creating FB against BO with
unsupported tiling
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/nouveau_display.c | 97
: -Rebased on nouveau linux-5.6 @ 137c4ba7163ad9d5696b9fde78b1c0898a9c115b
-Noted corresponding Mesa patches are production-worthy now
-Better validate bo tile_mode when checking framebuffer size.
James Jones (3):
drm/nouveau: Add format mod prop to base/ovly/nvdisp
drm/nouveau: Check frameb
.
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/dispnv50/base507c.c | 7 +--
drivers/gpu/drm/nouveau/dispnv50/disp.c | 59 +
drivers/gpu/drm/nouveau/dispnv50/disp.h | 4 ++
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 27 +-
drivers/gpu/drm/nouveau/dispnv50
en
needed, but it is simpler and likely less error-prone with the wrapper
struct.
Thanks,
-James
On 2/6/20 2:19 AM, Thomas Zimmermann wrote:
After its cleanup, struct nouveau_framebuffer is only a wrapper around
struct drm_framebuffer. Use the latter directly.
Signed-off-by: Thomas Zimmermann
---
drive
meaningful, so I suspect those fields will be effectively
deprecated in favor of the modifier-defined and, for non-FB operations,
strictly userspace defined layout. Doing so will be much easier if the
modifier support is already in place for applications to start making
use of.
Thanks,
-James
as commonly, but
applications could do the same thing with EGLImage + modifiers in GL, at
least at the API level and I believe on other vendors' Mesa drivers.
Thanks,
-James
On 2/6/20 7:47 AM, Ilia Mirkin wrote:
So ... for Vulkan, the API requires allocating VA before declaring
what goes into that VA
Yes, that's certainly viable. If that's the general preference in
direction, I'll rework that patches to do so.
Thanks,
-James
On 2/6/20 7:49 AM, Thomas Zimmermann wrote:
Hi James
Am 06.02.20 um 16:17 schrieb James Jones:
Note I'm adding some fields to nouveau_framebuffer in the series
Yes, that's certainly viable. If that's the general preference in
direction, I'll rework that patches to do so.
Thanks,
-James
On 2/6/20 7:49 AM, Thomas Zimmermann wrote:
Hi James
Am 06.02.20 um 16:17 schrieb James Jones:
Note I'm adding some fields to nouveau_framebuffer in the series
display hardware.
v2: Used Tesla family instead of NV50 chipset compare
v4: Do not cache kind, tile_mode in nouveau_framebuffer
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 18 +++--
drivers/gpu/drm/nouveau/nouveau_display.c | 90 ++-
drivers/gpu/drm
sting code.
v3: -Rebased on nouveau linux-5.6 @ 137c4ba7163ad9d5696b9fde78b1c0898a9c115b
-Noted corresponding Mesa patches are production-worthy now
-Better validate bo tile_mode when checking framebuffer size.
v4: Do not cache kind, tile_mode in nouveau_framebuffer
James Jones (3):
drm/no
Make sure framebuffer dimensions and tiling
parameters will not result in accesses beyond the
end of the GEM buffer they are bound to.
v3: Return EINVAL when creating FB against BO with
unsupported tiling
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/nouveau_display.c | 97
.
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/dispnv50/base507c.c | 7 +--
drivers/gpu/drm/nouveau/dispnv50/disp.c | 59 +
drivers/gpu/drm/nouveau/dispnv50/disp.h | 4 ++
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 27 +-
drivers/gpu/drm/nouveau/dispnv50
, but if these
cleanup patches are taken, only v4 will work.
Thanks,
-James
On 2/6/20 8:45 AM, James Jones wrote:
Yes, that's certainly viable. If that's the general preference in
direction, I'll rework that patches to do so.
Thanks,
-James
On 2/6/20 7:49 AM, Thomas Zimmermann wrote:
Hi James
Am 06.02.20
On 2/10/20 3:35 PM, Ben Skeggs wrote:
On Tue, 11 Feb 2020 at 09:17, James Jones wrote:
On 2/10/20 12:25 AM, Thomas Zimmermann wrote:
Hi
Am 10.02.20 um 09:20 schrieb Ben Skeggs:
On Sat, 8 Feb 2020 at 07:10, James Jones wrote:
I've sent out a v4 version of the format modifier patches
On 1/5/20 5:25 PM, Ben Skeggs wrote:
On Tue, 17 Dec 2019 at 10:45, James Jones wrote:
Make sure framebuffer dimensions and tiling
parameters will not result in accesses beyond the
end of the GEM buffer they are bound to.
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau
On 1/5/20 5:30 PM, Ben Skeggs wrote:
On Tue, 17 Dec 2019 at 10:44, James Jones wrote:
This series modifies the NV5x+ nouveau display backends to advertise
appropriate format modifiers on their display planes in atomic mode
setting blobs.
Corresponding modifications to Mesa/userspace
ld %s at %d to
> 0x%x\n", \
> #symbol, A_##symbol##_used[i], val)); \
> } \
If you're going to change the macros from taking a device to taking a
hostdata structure then the descriptive argument name needs to change
... it can't be dev anymore. I'm happy with it si
On Tue, 2020-09-01 at 16:05 +0100, Matthew Wilcox wrote:
> On Tue, Sep 01, 2020 at 07:52:40AM -0700, James Bottomley wrote:
> > I think this looks mostly OK, except for one misnamed parameter
> > below. Unfortunately, the last non-coherent parisc was the 700
> > series and
> &(script)[A_##symbol##_used[i]], 4); \
> DEBUG((" script, patching short field %s at %d to
> 0x%x\n", \
> #symbol, A_##symbol##_used[i], val)); \
> } \
These macro arguments need updating. Since you changed the input from
hostdata->dev to hostdata, leaving the macro argument as dev is simply
misleading. It needs to become hostdata or h.
James
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On Sun, 2020-10-18 at 20:16 +0100, Matthew Wilcox wrote:
> On Sun, Oct 18, 2020 at 12:13:35PM -0700, James Bottomley wrote:
> > On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote:
> > > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > > > cla
t some spam filter on the list that mangles URLs
this way.
James
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
-off-by: James Jones
---
drivers/gpu/drm/nouveau/nouveau_display.c | 26 +--
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 496c4621cc78..31543086254b 100644
--- a/drivers
.
Thanks,
-James
On 7/17/20 11:57 AM, James Jones wrote:
Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
family of modifiers to handle broken userspace
Xorg modesetting and Mesa drivers.
Tested with Xorg 1.20 modesetting driver,
weston@c46c70dac84a4b3030cd05b380f9f410536690fc,
gnome & KDE way
tree if you weren't already. I was testing with
drm-fixes-2020-07-17-1 from here:
git://anongit.freedesktop.org/drm/drm
Thanks,
-James
On 7/17/20 8:13 PM, James Jones wrote:
This doesn't look related.
-James
On 7/17/20 2:30 PM, Kirill A. Shutemov wrote:
On Fri, Jul 17, 2020 at 11:57:57AM
On 7/17/20 12:47 PM, Daniel Vetter wrote:
On Fri, Jul 17, 2020 at 11:57:57AM -0700, James Jones wrote:
Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
family of modifiers to handle broken userspace
Xorg modesetting and Mesa drivers.
Tested with Xorg 1.20 modesetting driver,
weston
This doesn't look related.
-James
On 7/17/20 2:30 PM, Kirill A. Shutemov wrote:
On Fri, Jul 17, 2020 at 11:57:57AM -0700, James Jones wrote:
Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
family of modifiers to handle broken userspace
Xorg modesetting and Mesa drivers.
Tested with Xorg 1.20
from Ubuntu 18.04,
and sway 1.5
Reported-by: Kirill A. Shutemov
Fixes: fa4f4c213f5f ("drm/nouveau/kms: Support NVIDIA format modifiers")
Link: https://lkml.org/lkml/2020/6/30/1251
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/nouveau_display.c | 26 +--
1 fi
On 7/23/20 9:06 PM, Ben Skeggs wrote:
On Sat, 18 Jul 2020 at 13:34, James Jones wrote:
Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
family of modifiers to handle broken userspace
Xorg modesetting and Mesa drivers. Existing Mesa
drivers are still aware of only these older
format modifiers
On 7/30/20 3:19 PM, Kirill A. Shutemov wrote:
On Thu, Jul 30, 2020 at 10:26:17AM -0700, James Jones wrote:
Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
family of modifiers to handle broken userspace
Xorg modesetting and Mesa drivers. Existing Mesa
drivers are still aware of only these older
from Ubuntu 18.04,
and sway 1.5
Reported-by: Kirill A. Shutemov
Fixes: fa4f4c213f5f ("drm/nouveau/kms: Support NVIDIA format modifiers")
Link: https://lkml.org/lkml/2020/6/30/1251
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/nouveau_display.c | 27 +--
1 fi
from Ubuntu 18.04,
kmscube hacked to use linear mod, and sway 1.5
Reported-by: Kirill A. Shutemov
Fixes: fa4f4c213f5f ("drm/nouveau/kms: Support NVIDIA format modifiers")
Link: https://lkml.org/lkml/2020/6/30/1251
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/nouveau_
On 7/29/20 7:47 AM, Kirill A. Shutemov wrote:
On Wed, Jul 29, 2020 at 01:40:13PM +1000, Ben Skeggs wrote:
On Wed, 29 Jul 2020 at 12:48, Dave Airlie wrote:
On Tue, 28 Jul 2020 at 04:51, James Jones wrote:
On 7/23/20 9:06 PM, Ben Skeggs wrote:
On Sat, 18 Jul 2020 at 13:34, James Jones
On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value
> > at all ... we really shouldn't be wasting maintainer time with it
> > because i
On Sun, 2020-11-22 at 21:35 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
> wrote:
> > Well, it's a problem in an error leg, sure, but it's not a really
> > compelling reason for a 141 patch series, is it? All that fixing
> > this error w
On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> wrote:
> > Well, I used git. It says that as of today in Linus' tree we have
> > 889 patches related to fall throughs and the first series went in
> > in october 20
On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> wrote:
> > Well, it seems to be three years of someone's time plus the
> > maintainer review time and series disruption of nearly a thousand
> > patches. Let's be
On Mon, 2020-11-23 at 07:03 -0600, Gustavo A. R. Silva wrote:
> On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > > On Sun,
fixing a significant problem, but they
did cause someone time and trouble to investigate.
James
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
All that fixing this
error will do is get the driver to print "oh dear there's a problem"
under four more conditions than it previously did.
We've been at this for three years now with nearly a thousand patches,
firstly marking all the fall throughs with /* fall through */ and later
changing it to fallthrough. At some point we do have to ask if the
effort is commensurate with the protection afforded. Please tell me
our reward for all this effort isn't a single missing error print.
James
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
1 - 100 of 120 matches
Mail list logo
