I don't really see anything between v5.0..v5.1 which would account for
this. Could have been a subtle change to the i2c logic somewhere. The
fastest way to identify the problem would be to do a bisect on the kernel
to identify the commit that caused this. There are many guides for this
online.
On
On Thu, Jun 13, 2019 at 9:15 AM Ilia Mirkin wrote:
>
> On Thu, Jun 13, 2019 at 2:35 AM Daniel Drake wrote:
> >
> > From: Lukas Wunner
> >
> > The integrated HDA controller on Nvidia GPUs can be hidden with a bit in
> > the GPU's config space. Info
This is done with a sequence of blits, from level 0 -> level 1, then
level 1 -> level 2, etc. st/mesa has a helper which will call the
gallium driver's blit method with the appropriate parameters.
Internally, assuming there's nothing too funky going on, we'll use the
2d blit logic (class 0x902d).
d HDA controller are two functions of the same PCI device
> (VGA class device on function 0 and audio device on function 1).
> The multifunction flag in the GPU's Header Type register is cleared when
> the HDA controller is hidden and set if it's exposed, so reread the flag
>
This adds support on GF119:GV100 (exclusive) for CTM (aka CSC).
Signed-off-by: Ilia Mirkin
---
v1 -> v2:
- ctm -> csc
- mark csc.valid = false when there is no ctm property
drivers/gpu/drm/nouveau/dispnv50/atom.h | 6 ++
drivers/gpu/drm/nouveau/dispnv50/base907c.
For GF119:GV100, we can enable DEGAMMA/CTM/GAMMA. For earlier GPUs, as
there is no CTM, having both degamma and gamma is a bit pointless. Later
GPUs currently lack an implementation.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/dispnv50/head.c | 5 +
1 file changed, 5 insertions
This adds support on GF119:GV100 (exclusive) for CTM (aka CSC).
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/dispnv50/atom.h | 6 ++
drivers/gpu/drm/nouveau/dispnv50/base907c.c | 65 +
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 13 +
drivers/gpu/drm
Here's what I know, which may or may not be accurate, and may or may
not be complete. You've been warned.
GRAPH.SERIALIZE (0x0110)
This is a method available on all GRAPH-engine classes (at least 3d
and 2d). What this does is that it tells the GRAPH engine (not FIFO!)
to wait until all previous d
The overlay logic can only do colorkey-based selection, not
alpha-blending.
Signed-off-by: Ilia Mirkin
---
This applies on top of the FP16 patch I sent earlier.
drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 --
drivers/gpu/drm/nouveau/dispnv50/ovly827e.c | 3 ---
drivers/gpu/drm/nouveau
On Thu, May 30, 2019 at 4:23 AM Markus Wanner wrote:
>
> Hello Karol,
>
> On 5/29/19 4:04 PM, Karol Herbst wrote:
> > If you want you could try out those patches on a kernel and see if
> > those make any difference on your machine:
> >
> > https://github.com/karolherbst/linux/commits/runpm_fixes
>
e, which
copies mode into adjusted_mode...
Assuming it makes sense to use "mode", Ben, want to just do a fixup
locally, or want me to send a revert + new patch?
-ilia
On Mon, May 27, 2019 at 2:24 AM Ben Skeggs wrote:
>
> On Sun, 26 May 2019 at 08:41, Ilia Mirkin wrote:
> &g
/show_bug.cgi?id=110660
Signed-off-by: Ilia Mirkin
---
Tested on a 1920x1200-native screen with a 640x480 mode (got letter
boxes on the side) and 720x400 mode (got letter boxes on top/bottom).
drivers/gpu/drm/nouveau/dispnv50/head.c | 28 +
1 file changed, 24 insertions(+), 4
, and i915 already does it this way.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110660
Signed-off-by: Ilia Mirkin
---
Untested for now, hoping that the bugzilla filer will test it out. Seems
obvious though.
drivers/gpu/drm/nouveau/dispnv50/disp.c | 9 +++--
1 file changed, 7 inser
On Tue, May 21, 2019 at 9:29 AM Karol Herbst wrote:
>
> On Tue, May 21, 2019 at 3:11 PM Bjorn Helgaas wrote:
> >
> > On Tue, May 21, 2019 at 12:30:38AM +0200, Karol Herbst wrote:
> > > On Mon, May 20, 2019 at 11:20 PM Bjorn Helgaas wrote:
> > > > On Tue, May 07, 2019 at 10:12:45PM +0200, Karol H
On Tue, May 14, 2019 at 3:57 PM Peteris Rudzusiks
wrote:
>
> On Tue, May 14, 2019 at 04:55:05PM +1000, Ben Skeggs wrote:
> > On Sun, 12 May 2019 at 04:23, Peteris Rudzusiks
> > wrote:
> > >
> > > nv50_head_atomic_duplicate_state() makes a copy of nv50_head_atom
> > > struct. This patch adds copyi
Hi Fernando,
Perhaps you can elaborate? The question doesn't really make sense to me.
What register are you talking about? Do you perhaps mean a method call
in the b197 class? (And what's 0xB2? Methods are always at multiples
of 4... do you mean 0x2c8 perhaps? If so, that's not documented post
Fe
On Tue, Mar 26, 2019 at 10:56 AM Trevor Woerner wrote:
>
> On Tue 2019-03-26 @ 10:40:49 AM, Ilia Mirkin wrote:
> > Just looked over the projects... they all seem valid
>
> Thank you for taking the time to have a look and provide feedback!
>
> > but are there
> &g
[-everyone except nouveau]
Just looked over the projects... they all seem valid, but are there
people who could realistically mentor a GSoC student for these? IMHO
unless mentors can be identified, these should all be archived.
Cheers,
-ilia
On Tue, Mar 26, 2019 at 10:32 AM Trevor Woerner wr
On Sat, Feb 16, 2019 at 12:49 PM Dan Espen wrote:
>
> Dan Espen writes:
>
> > Ilia Mirkin writes:
> >
> >> On Wed, Feb 6, 2019 at 3:28 PM Dan Espen wrote:
> >>>
> >>> Ilia Mirkin writes:
> >>>
> >>> > It
omething up when undoing it than just
leaving it alone. (Why did NVIDIA choose to start their hardware
format enums at 0xc0? No clue. But it's what the HW expects...)
Hope this helps,
-ilia
>
>
> > On 24 Nov 2018, at 12:20 PM, Ilia Mirkin wrote:
> >
> > On Fri, N
On Sat, Feb 16, 2019 at 10:02 AM Colin Ian King
wrote:
>
> Hi,
>
> Static Analysis with CoverityScan as detected an issue with the setting
> of the RON pull value in function nvkm_gddr3_calc in
> drm/nouveau/bios/ramcfg.c
>
> This was introduced by commit: c25bf7b6155cb ("drm/nouveau/bios/ramcfg:
On Wed, Feb 6, 2019 at 3:28 PM Dan Espen wrote:
>
> Ilia Mirkin writes:
>
> > It would be useful to know how the screen is connected. Also please
> > grab the monitor's EDID from /sys/class/drm/cardN-connector/edid and
> > attach it here. It would also b
It would be useful to know how the screen is connected. Also please
grab the monitor's EDID from /sys/class/drm/cardN-connector/edid and
attach it here. It would also be interesting to get a boot with
"drm.debug=0x1e nouveau.debug=disp=trace" which has the modeswitch in
question.
The thing about 6
Miptree layout for linear textures:
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nv50/nv50_miptree.c#n238
Setting for RTs:
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c#n224
Follow the !nouveau_bo_memtype path (and
: Validate the atom for enum properties
Ilia Mirkin (10):
man: remove reference to glamor under DRI option
dri3: remove bogus condition for creating pixmap
nv50/xv: add support for depth 30 xv output
dri3: don't check permissions on render node
drmmode: provide b
---
man/nouveau.man | 9 -
src/nv_driver.c | 8 ++--
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/man/nouveau.man b/man/nouveau.man
index 07d53c8..4878f24 100644
--- a/man/nouveau.man
+++ b/man/nouveau.man
@@ -63,7 +63,14 @@ GF100, GF104, GF106, GF108, GF110, GF114,
The "pick best" logic takes rotation into account. However flipping a
rotated CRTC can't work, so we disable that.
Signed-off-by: Ilia Mirkin
---
At first blush, this seems to make DRI3 function reasonably with rotated
CRTCs
src/nouveau_present.c | 5 +
1 file changed, 1
This causes nouveau_drv.so to not be loadable due to a missing
wfbPictureInit. I'm not 100% sure what causes it -- it happens at
runtime in the middle of probe, and I don't have wfb enabled. Either
way, I'm going to revert this until we get a better idea of what's
going on.
On Sun, Jan 20, 2019 at
The scenario you describe should most definitely work -- switching
between different instances of X running on different vt's.
Your GPU has 4 CRTC's (Kepler, then Maxwell, then Pascal -- that's
your generation), which means you can have up to 4 heads at the same
time.
Here's a config that I use t
Thanks, applied.
On Mon, Jan 21, 2019 at 12:52 AM Rhys Kidd wrote:
>
> Series of cleanups to autotools build config files to utilize the available
> xorg-server macros, defaults and more closely match other modern Xorg drivers.
>
> Notable improvements:
> - gitignore fully covers potential build
Hi Janek,
A few things...
First off, you're not using the nouveau ddx, you're using the
modesetting ddx. This isn't a problem in itself, but if you're going
to report bugs, you should file them against the proper component.
Secondly, I'm a bit unclear as to what your setup is. A single X
server
Thanks, series applied.
On Sun, Jan 20, 2019 at 10:21 PM Rhys Kidd wrote:
>
> A short series of compiler visibility warning fixes that I prepared whilst
> trialing improvements to xf86-video-nouveau's use of the core xorg-server
> utility macros.
>
> Rhys Kidd (4):
> wfb: Remove declaration for
Thanks, series pushed.
On Sun, Jan 20, 2019 at 9:31 PM Rhys Kidd wrote:
>
> Warning reported by gcc 8.2:
>
> nouveau_xv.c: In function ‘NVPutImage’:
> nouveau_xv.c:1369:7: warning: declaration of ‘ret’ shadows a previous local
> [-Wshadow]
>int ret = BadImplementation;
>^~~
> nouveau
Probably needs more investigation. The relevant patch for amdgpu is
https://lists.x.org/archives/xorg-devel/2017-April/053439.html --
needs checking to see what this is all talking about.
On Sun, Jan 20, 2019 at 1:51 PM Ilia Mirkin wrote:
>
> Apparently it now wants a drawable.
>
> S
Apparently it now wants a drawable.
Signed-off-by: Ilia Mirkin
---
No idea about whether this is correct. Saw the new warnings though.
src/drmmode_display.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
On Sat, Jan 19, 2019 at 6:38 PM Rhys Kidd wrote:
>
> On Sat, 19 Jan 2019 at 18:32, Ilia Mirkin wrote:
>>
>> Is vlCreateAdaptorXvMC just silly, or does it really want to take
>> ownership of the name pointer?
>
>
> vlCreateAdaptorXvMC( ) doesn't need to take
Is vlCreateAdaptorXvMC just silly, or does it really want to take
ownership of the name pointer?
On Sat, Jan 19, 2019 at 6:30 PM Rhys Kidd wrote:
>
> Fixes warning with gcc 8.2:
>
> nouveau_xv.c: In function ‘NVInitVideo’:
> nouveau_xv.c:2247:68: warning: passing argument 2 of ‘vlCreateAdaptorXvM
GF117 appears to use the same register as GK104 (but still with the
general Fermi readout mechanism).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980
Signed-off-by: Ilia Mirkin
---
v1 -> v2: split out different regid into separate file.
.../drm/nouveau/include/nvkm/subdev/vol
On Sat, Jan 5, 2019 at 10:36 PM K. York wrote:
>
> > Opinions welcome.
>
> I have a few ideas on the best way to approach this.
>
> - First of all, obviously, fix the WebGL CTS problems. (with
> --ignore-gpu-blacklist )
> - Fix all other crashing issues and request re-inclusion. (This is
> comme
It looks like as of Chromium 71, nouveau is completely blacklisted.
I don't really see a way back from this, since they don't cite any
easily reproducible issues, except that some people had some issues
with indeterminate hardware and indeterminate versions of mesa.
In the bug that triggered this
On Tue, Jan 1, 2019 at 5:30 PM Jan Vlietland wrote:
>
> Hi Ilia, many thanks for answering my mail.
>
> Tonight I tried to see what happens if I generate a xorg.conf file and place
> it in /etc/X11/xorg.conf, as described here:
> https://askubuntu.com/questions/4662/where-is-the-x-org-config-file
On Tue, Jan 1, 2019 at 4:06 PM Jan Vlietland wrote:
>
> Hi Ben, David and Daniel ,
>
> First of all happy new year. Based on advice of Greg K-H herewith a mail
> about a number of Nouveau issues with my laptop.
>
> I installed various Kali linux versions up to Linux 4.20.0-rc7
> (downloaded, compi
Ben - ping? Just ran into this myself on a NV42.
On Wed, Nov 14, 2018 at 11:01 AM Takashi Iwai wrote:
>
> On Fri, 14 Sep 2018 13:59:25 +0200,
> Martin Peres wrote:
> >
> > On 14/09/2018 10:28, Ben Skeggs wrote:
> > > On Wed, 12 Sep 2018 at 20:59, Takashi Iwai wrote:
> > >>
> > >> When a fan is c
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nvkm/engine/falcon.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/falcon.c
b/drivers/gpu/drm/nouveau/nvkm/engine
GF117 appears to use the same register as GK104 (but still with the
general Fermi readout mechanism).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gf100.c | 3 ++-
1 file changed, 2 insertions(+), 1
On Tue, Dec 11, 2018 at 11:16 AM riveravaldez
wrote:
>
> > Use an environment that doesn't make use of GL for basic tasks.
>
> I've been researching more and it seems that I'm already in that case.
> The freezes appears randomly, in every situation, and not when I
> launch some 3D applications or
On Sun, Dec 9, 2018 at 12:24 AM James wrote:
>
> 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
On Thu, Dec 6, 2018 at 7:11 AM riveravaldez wrote:
> [ 16.573419] nouveau :00:0d.0: bus: MMIO write of 005c0001 FAULT at
> 00b000
This is not a big deal. We write to some register that doesn't exist,
but we don't use that engine anyways -- it's the media engine, I
think.
> So, what could/
On Fri, Nov 23, 2018 at 11:00 PM Yang Tsao wrote:
>
> Hi, guys:
> I’m a developer of FydeOS. We porting ChromiumOS to amd64 and arm platforms.
> Now, I’m woking on porting android environment to Nvidia graphic cards. I
> have experience to port android to Vmware(SVGA).
> I found two display form
On Mon, Nov 12, 2018 at 6:11 PM Fernando Sahmkow wrote:
>
> So I'm trying to track an special value in IPA instruction generation.
> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp#L2561
>
> Register on 0x14 (20) is set to some source on "insn
On Wed, Nov 7, 2018 at 10:34 AM Thierry Reding wrote:
>
> On Tue, Nov 06, 2018 at 06:41:22PM +0200, Ville Syrjälä wrote:
> > On Tue, Nov 06, 2018 at 05:24:15PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > Irrespective of whether or not the device has any usable outputs, the
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c#n190
On Thu, Oct 25, 2018 at 6:30 AM Fernando Sahmkow wrote:
>
> I'm currently implementing mipmaps but I have a set of troubles guessing the
> block height and block depth of them. According to
> https:/
On Fri, Oct 19, 2018 at 8:53 AM 孫偉程 wrote:
> I can imagine there is a long way to go to fulfill my requirements. But I
> know a driver for my NVIDIA card is a must for the hardware decoder to work.
> Can somebody shed some lights that if I want to play an 8K HEVC encoded video
> on Android-x86
On Sat, Oct 13, 2018 at 5:40 PM Fernando Sahmkow wrote:
>
> So there's a register in Render Targets called Array Mode:
> https://github.com/envytools/envytools/blob/master/rnndb/graph/gf100_3d.xml#L289
>
> We've witnessed values of 1 and 6 (array mode -> layers) but we can't tell
> their meaning.
This largely copies the code from modesetting with minor adjustments.
Signed-off-by: Ilia Mirkin
---
I've tested this back and forth with a GTX 960 + 2x U2415 monitors,
chained to each other. I turned them on/off. I messed with their DP
1.1/1.2 settings. I pulled plugs a few times.
This
On Sun, Sep 23, 2018 at 1:48 PM, Wolfgang Rißler wrote:
> Am Sonntag, den 23.09.2018, 12:55 -0400 schrieb Ilia Mirkin:
>> On Sun, Sep 23, 2018 at 12:26 PM, Wolfgang Rißler
>> wrote:
> [snip]
>>
>> That's not extremely surprising ... force-enabling an output I
On Sun, Sep 23, 2018 at 12:26 PM, Wolfgang Rißler wrote:
> I try to send a friendly ping to my problem.
> At the moment I'm running at 1600x1200 (monitor than has 1600x1200
> too), what looks better then 1920x1200 picture on that Monitor with
> 960x1200.
> I cant get 1920x1200 working, but I'm shu
Swizzling is implemented by the hardware. Nouveau doesn't implement it
directly -- we just blit from a linear surface into a swizzled
surface.
Ideally you should be able to ignore swizzling entirely. However if an
application uploads pre-swizzled data, you have to deal with it. This
isn't possible
Doesn't look like the GV100 firmware is publicly available yet.
However it won't affect you at all - you only need the GP106 firmware.
Without more info, your issue could potentially be helped by
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=85c5d90fc155d78
DC = depth compare (extra arg with compare reference)
AOFFI = texel offset (extra arg with offsets encoded). Note that TLD4
can also have a iirc AOFFIS variant which takes 4 offsets encoded in 2
sequential regs. and iirc at 8 bits per offset, while other ops do 4
bits per offset. check what nouveau
Scrambling is required for supporting any mode over 340MHz. If it's not
supported, reject any modes that would require it.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 34 +++--
1 file changed, 22 insertions(+), 12 deletions(-)
diff
When SCDC is supported, make sure that we configure the GPU and monitor
to the same parameters.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 40 -
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/Kbuild| 1 +
.../gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c | 34 ++
drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h | 2 ++
.../gpu/drm/nouveau/nvkm/engine/disp/sorgm200.c| 1 +
.../gpu
The register programmed by the clock method needs to contain a different
setting for the link speed as well as special divider settings.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c | 2 ++
drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h | 5
High pixel clocks are required to use a 40 TMDS divider instead of 10,
and even low ones may optionally use scrambling depending on device
support.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/include/nvif/cl5070.h | 5 -
drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h
d by one or the
other. But at least it works a little bit!
Note that I have limited testing equipment, but I did verify that a
GM204 trace referred to the same register for controlling
scrambling. I may get access to a GM206 later in the week to verify
there.
Ilia Mirkin (5):
drm/nouveau/disp: add
IPA is to interpolate an input in a fragment shader. Have a look at
OP_LINTERP / OP_PINTERP in codegen
(https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/).
Also feel free to ask specific questions in #nouveau on
irc.freenode.net.
Cheers,
-ilia
On Sat, Sep 1, 2018
On Mon, Aug 13, 2018 at 3:07 PM, Lyude Paul wrote:
> +bool
> +nouveau_fbcon_hotplugged_in_suspend(struct nouveau_fbdev *fbcon)
> +{
> + bool hotplug;
> +
> + if (!fbcon)
> + return false;
> +
> + mutex_lock(&fbcon->hotplug_lock);
> + hotplug = fbcon->hotplug_w
GP106 is supported, you must be using an older kernel (since yours
says "unknown chipset"). Note that mobile chips, esp GP10x's, appear
to have a ton of issues with runtime pm, so YMMV.
On Sat, Aug 4, 2018 at 7:37 PM, don fisher wrote:
> I had desire for a light laptop, so purchased an Alienware
On Fri, Aug 3, 2018 at 8:19 AM, Karol Herbst wrote:
> v2: clean up left over comments
> don't overwrite hdmimhz parameter
> cap to 297MHz
>
> Signed-off-by: Karol Herbst
> ---
> drm/nouveau/dispnv50/disp.c | 5 +
> drm/nouveau/nouveau_connector.c | 15 ++-
> drm/nouv
This removes user control to force a hdmimhz. Given the vast variety
of hardware and display configurations out there, I don't see how a
patch like this won't blow up in our faces.
I'm not saying we shouldn't do it -- we should attempt to respect the
various maximums in the vbios, but until we get
On Tue, Jun 26, 2018, 04:49 Dan Carpenter wrote:
> Hello Ben Skeggs,
>
> The patch a9c44a88ca2f: "drm/nouveau/disp/nv50-: add channel
> interfaces to control error interrupts" from May 8, 2018, leads to
> the following static checker warning:
>
> drivers/gpu/drm/nouveau/nvkm/engine/disp/c
Did you accidentally send this to the nouveau list instead of the chromium one?
On Tue, Jun 19, 2018 at 10:09 AM, 積丹尼 Dan Jacobson wrote:
> chromium prints thousands of
> [1886:1886:0619/220640.036283:ERROR:gl_surface_presentation_helper.cc(115)]
> GetVSyncParametersIfAvailable() failed!
> _
On Sun, Jun 17, 2018 at 8:50 PM, Yoann LE BARS wrote:
>
> Hello everybody out there!
>
> Well, I just subscribed to this mailing list, so I guess I should
> introduce myself, at least giving relevant information about me
> concerning the development of Nouveau.
>
> You can call me
Lyude bisected a similar problem on a much newer GPU to this very same
change as well. [Sorry, no useful information beyond that, but thought
I'd make the connection.]
On Sun, Jun 17, 2018 at 5:46 PM, Adam Borowski wrote:
> Hi!
> On v4.18-rc1, the mouse cursor is missing on my right monitor.
> Ca
On Tue, Jun 12, 2018 at 9:09 PM, 積丹尼 Dan Jacobson wrote:
>>>>>> "IM" == Ilia Mirkin writes:
>
> IM> OK, well 18.1.0 is completely busted for those GPU's. Either upgrade
> IM> or downgrade. But don't use that release.
>
> I did
> [DO
Where did you see instructions for doing this? Apparently this is
disabled on purpose due to spam. Or did you just assume it would work
based on other mailman lists?
On Mon, Jun 11, 2018 at 1:08 PM, Dan Jacobson wrote:
> Can't join the list confirming via email.
> Will get:
>
> gabe.freedeskt
On Mon, Jun 11, 2018 at 1:32 PM, 積丹尼 Dan Jacobson wrote:
> # lspci | grep ' VGA ' | cut -d" " -f 1 | xargs -i lspci -v -s {}
> 00:05.0 VGA compatible controller: NVIDIA Corporation C51G [GeForce 6100]
> (rev a2) (prog-if 00 [VGA controller])
That's a NV4C or NV4E (i.e. nv4x).
> I.e., no 18.1.1
Are you on mesa 18.1.0 and using a nv3x/nv4x gpu? If so, update to
18.1.1. If not, provide more information.
The error is that nouveau_dri.so can't be loaded, which means you're
not getting acceleration. You can also make the error go away by
sticking LIBGL_ALWAYS_SOFTWARE=1 into your environment
On Sun, May 27, 2018 at 5:54 PM, Colin King wrote:
> From: Colin Ian King
>
> The constant values being shifted are 32 bit integers and may potentially
> overflow on the shift. Avoid this potential overflow by making them
> unsigned long long values before the shift.
>
> Detected by CoverityScan
On Tue, May 1, 2018 at 6:16 PM, James wrote:
> On 2018-05-01 06:00 PM, Ilia Mirkin wrote:
>> On Tue, May 1, 2018 at 5:53 PM, James wrote:
>>> I am playing videos from my lubuntu computer to my tv through the hdmi
>>> interface on my video card.
>>> It mostly
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 wrote:
> 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
On Thu, Mar 8, 2018 at 11:29 PM, Ilia Mirkin wrote:
> On Mon, Mar 5, 2018 at 7:33 AM, Ilia Mirkin wrote:
>> On Mon, Mar 5, 2018 at 1:17 AM, Mario Kleiner
>> wrote:
>>> On 03/03/2018 12:59 AM, Ilia Mirkin wrote:
>>>>
>>>> On Fri, Mar 2, 2018 at 6:
A NV34 GPU was seeing temp and pwm entries in hwmon, which would error
out when read. These should not have been visible, but also the whole
hwmon object should just not have been registered in the first place.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 16
On Wed, Apr 4, 2018 at 6:58 PM, Adam Borowski wrote:
> On Wed, Apr 04, 2018 at 03:48:39PM +0300, Māris Nartišs wrote:
>> 2018-04-03 23:00 GMT+03:00, Adam Borowski :
>> > In commit da5e45e619b3f101420c38b3006a9ae4f3ad19b0
>> >
>> > yet it is still reproducible for me on 4.16-rc7 and 4.16.0, which a
On Mon, Mar 5, 2018 at 7:33 AM, Ilia Mirkin wrote:
> On Mon, Mar 5, 2018 at 1:17 AM, Mario Kleiner
> wrote:
>> On 03/03/2018 12:59 AM, Ilia Mirkin wrote:
>>>
>>> On Fri, Mar 2, 2018 at 6:46 PM, Mario Kleiner
>>> wrote:
>>>>
>>>> On
On Thu, Mar 8, 2018 at 11:57 AM, Mario Kleiner
wrote:
> Cc'ing mesa-dev, which was left out.
>
>
> On 03/05/2018 01:40 PM, Ilia Mirkin wrote:
>>
>> On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner
>> wrote:
>>> Afaics EGL does the right thing wr
sonable state in the entry in slot #0: as I
> understand it, the one piece of sampler state that will influence TLD
> is sRGBConversion (bit 13).
>
> I hope that helps,
> - Andy
>
>
> On Thu, Mar 01, 2018 at 11:47:18PM -0500, Ilia Mirkin wrote:
>> Hello,
>>
>>
On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner
wrote:
> On 02/05/2018 12:50 AM, Ilia Mirkin wrote:
>>
>> In case anyone's curious about 30bpp framebuffer support, here's the
>> current status:
>>
>> Kernel:
>>
>> Ben and I have switched the
On Mon, Mar 5, 2018 at 1:17 AM, Mario Kleiner
wrote:
> On 03/03/2018 12:59 AM, Ilia Mirkin wrote:
>>
>> On Fri, Mar 2, 2018 at 6:46 PM, Mario Kleiner
>> wrote:
>>>
>>> On 03/02/2018 11:29 PM, Ilia Mirkin wrote:
>>>>
>>>> OK, s
On Fri, Mar 2, 2018 at 6:46 PM, Mario Kleiner
wrote:
> On 03/02/2018 11:29 PM, Ilia Mirkin wrote:
>> OK, so even if you're passing 1024 to xf86HandleColormaps, gamma_set
>> still only gets called with a 256-entry LUT? If so, that works nicely
>> here, but is not int
On Fri, Mar 2, 2018 at 5:16 PM, Mario Kleiner
wrote:
> On 03/01/2018 07:21 PM, nouveau-requ...@lists.freedesktop.org wrote:
>>
>>
>> Message: 1
>> Date: Thu, 1 Mar 2018 08:15:55 -0500
>> From: Ilia Mirkin
>> To: Mario Kleiner
>> Cc: nouveau
&
Hello,
This question is in the context of Tesla / Fermi generations, which
have explicit bindings for textures / samplers. It might also apply to
Kepler+, not quite as sure due to the bindless nature.
I've been trying to understand how the TLD operation works (which is
used to implement texelFetc
NVLoadPalette is pretty hard-coded to 256. I haven't looked at what
all xf86HandleColormaps does, but it seems pretty suspicious. Also
note that the kernel currently only exposes a 256-sized LUT to
userspace, even for 10bpc modes.
On Thu, Mar 1, 2018 at 1:31 AM, Mario Kleiner
wrote:
> The various
On Tue, Feb 20, 2018 at 9:25 AM, Ilia Mirkin wrote:
> On Tue, Feb 20, 2018 at 8:48 AM, Ville Syrjala
> wrote:
>> From: Ville Syrjälä
>>
>> Replace the ad-hoc iturbt_709 property with the new standard
>> COLOR_ENCODING property. Compiles, but not tested.
>>
On Tue, Feb 20, 2018 at 8:48 AM, Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> Replace the ad-hoc iturbt_709 property with the new standard
> COLOR_ENCODING property. Compiles, but not tested.
>
> Cc: Daniel Vetter
> Cc: nouveau@lists.freedesktop.org
> Cc: Ben S
On Wed, Feb 14, 2018 at 9:35 AM, Ilia Mirkin wrote:
> On Wed, Feb 14, 2018 at 9:29 AM, Meelis Roos wrote:
>>> This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in 4.15:
>>
>> NV5 in another PC (secondary card in x86-64) made the systrem crash on
>> bo
On Wed, Feb 14, 2018 at 9:29 AM, Meelis Roos wrote:
>> This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in 4.15:
>
> NV5 in another PC (secondary card in x86-64) made the systrem crash on
> boot, in nvkm_therm_clkgate_fini.
Mind booting with nouveau.debug=trace? That should hopeful
The permission check fails if udev sets the render node to 0666 but
leaves the card at 0660, as is done in at least udev-236.
Signed-off-by: Ilia Mirkin
---
src/nouveau_dri2.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/src/nouveau_dri2.c b/src
On Wed, Feb 7, 2018 at 12:01 PM, Ville Syrjälä
wrote:
> On Wed, Feb 07, 2018 at 06:28:42PM +0200, Ville Syrjälä wrote:
>> On Sun, Feb 04, 2018 at 06:50:45PM -0500, Ilia Mirkin wrote:
>> > In case anyone's curious about 30bpp framebuffer support, here's the
>>
201 - 300 of 1419 matches
Mail list logo
