https://bugs.freedesktop.org/show_bug.cgi?id=82441
Martin Peres <martin.peres(a)free.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|NEW |RESOLVED
--- Comment #4 from Martin Peres <martin.peres(a)free.fr> ---
Hi,
Freedesktop's Bugzilla instance is EOLed and open bugs are about to be migrated
to http://gitlab.freedesktop.org.
To avoid migrating out of date bugs, I am now closing all the bugs that did not
see any activity in the past year. If the issue is still happening, please
create a new bug in the relevant project at https://gitlab.freedesktop.org/drm
(use misc by default).
Sorry about the noise!
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=733
Martin Peres <martin.peres(a)free.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|NEW |RESOLVED
--- Comment #9 from Martin Peres <martin.peres(a)free.fr> ---
Hi,
Freedesktop's Bugzilla instance is EOLed and open bugs are about to be migrated
to http://gitlab.freedesktop.org.
To avoid migrating out of date bugs, I am now closing all the bugs that did not
see any activity in the past year. If the issue is still happening, please
create a new bug in the relevant project at https://gitlab.freedesktop.org/drm
(use misc by default).
Sorry about the noise!
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=11968
Martin Peres <martin.peres(a)free.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #6 from Martin Peres <martin.peres(a)free.fr> ---
Hi,
Freedesktop's Bugzilla instance is EOLed and open bugs are about to be migrated
to http://gitlab.freedesktop.org.
To avoid migrating out of date bugs, I am now closing all the bugs that did not
see any activity in the past year. If the issue is still happening, please
create a new bug in the relevant project at https://gitlab.freedesktop.org/drm
(use misc by default).
Sorry about the noise!
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=3832
Martin Peres <martin.peres(a)free.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|NEW |RESOLVED
--- Comment #3 from Martin Peres <martin.peres(a)free.fr> ---
Hi,
Freedesktop's Bugzilla instance is EOLed and open bugs are about to be migrated
to http://gitlab.freedesktop.org.
To avoid migrating out of date bugs, I am now closing all the bugs that did not
see any activity in the past year. If the issue is still happening, please
create a new bug in the relevant project at https://gitlab.freedesktop.org/drm
(use misc by default).
Sorry about the noise!
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=8191
Martin Peres <martin.peres(a)free.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #7 from Martin Peres <martin.peres(a)free.fr> ---
Hi,
Freedesktop's Bugzilla instance is EOLed and open bugs are about to be migrated
to http://gitlab.freedesktop.org.
To avoid migrating out of date bugs, I am now closing all the bugs that did not
see any activity in the past year. If the issue is still happening, please
create a new bug in the relevant project at https://gitlab.freedesktop.org/drm
(use misc by default).
Sorry about the noise!
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=71083
Priority: medium
Bug ID: 71083
Assignee: dri-devel(a)lists.freedesktop.org
Summary: (struct drm_encoder_helper_funcs)->mode_set not
re-called after display (and EDID) change
Severity: normal
Classification: Unclassified
OS: All
Reporter: zajec5(a)gmail.com
Hardware: Other
Status: NEW
Version: unspecified
Component: DRM/other
Product: DRI
I use my DCE5 Barts (HD69xx) with AV-receiver Onkyo TX-SR605 and one of the
following displays:
1) TV Sony Bravia KDL-52X3500
2) Projector Epson EH-TW6100
My problem is that when I change display connected to the Onkyo's output EDID
changes, but drm doesn't call mode_set as long as I use the same resolution.
To force drm to call mode_set I've to change resolution (xrandr --output HDMI-0
--mode X) and then swtich back to the mode I want.
While the display seems to be working fine without that mode_set call, the
audio engine doesn't. As part of the modesetting handler we read ELD-related
info from EDID and write it to the audio engine of the GPU. Without this
happening I can't play correctly audio (because also sees info about previous
device, not the current one).
I think mode_set should be called every time EDID changes. Is that right?
In case someone's curious:
1) EDID with Onkyo + Sony TV:
00ffffffffffff003dcb610700000000
0011010380a05a780a0dc9a057479827
12484c21080081800101010101010101
010101010101023a801871382d40582c
450040846300001e011d007251d01e20
6e28550040846300001e000000fc0054
582d53523630350a20202020000000fd
00303e0e460f000a2020202020200185
02034c705c1f03041213051420071610
15110206010f1e0b1a191d0e0a242625
2335097f070f7f071707503f06c05706
005f7e01671e00834f00006c030c0012
00b82dc000000000e3050301023a80d0
72382d40102c458040846300001e011d
00bc52d01e20b828554040846300001e
00000000000000000000000000000078
2) EDID with Onkyo + Epson projector:
00ffffffffffff004ca333d000000000
0c150104952616780aa0558d515a962a
1c505400000001010101010101010101
0101010101016a4d80a07038fc413020
36007ed710000018d49a80a07038fc41
302036007ed710000038000000fc0053
414d53554e470a2020202020000000fc
00313733485430322d4330310a200035
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=92481
Bug ID: 92481
Summary: [Patch] Mostly cosmetic changes for
drm_dp_mst_i2c_xfer in Linux 4.3-rc5
Product: DRI
Version: unspecified
Hardware: Other
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: DRM/other
Assignee: dri-devel(a)lists.freedesktop.org
Reporter: adam_richter2004(a)yahoo.com
Created attachment 118905
--> https://bugs.freedesktop.org/attachment.cgi?id=118905&action=edit
Numerous mostly cosmetic fixed to drm_dp_mst_i2c_xfer in linux
4.3-rc5/drivers/gpu/drm/drm_dp_mst_topology.c AFTER Dave Airlie's other changes
have been applied
Thanks to Dave Airlie and Daniel Vitter for the the fixes to
drm_dp_mst_i2c_xfer to avoid possibly sending unitialized data in DisplayPort
multistream tranport i2c queries and to enforce the limit on the number of i2c
transactions in a single i2c request to avoid a possible buffer overflow.
The attached patch is based on the file with Dave's aforementioned changes
applied. It is an a bunch of mostly cosmetic ("maintainability") changes,
which I will list below:
a. Move the parameter validations to before the call to
drm_dp_get_validated_mstb_ref(), so that, if they fail, they do not need to use
"goto out", thereby reducing the number of goto's and the longest distance
between a goto and its target label. I imagine it also makes these rare
failure cases a few nanoseconds faster without delaying the common case.
b. Because of the above, txmsg no longer needs to be initialized to NULL.
c. Have different error messages and error codes (E2BIG, and EINVAL) for num >
4 and the i2c transaction not ending with a read statement, for clearer
debugging if either of these errors should occur, which should help in cases
where the errors only occur sporadically or the person observing the error
cannot easily recompile and install a new kernel to get more information.
Error reproduction is precious, so it's best not to waste them with unnecessary
ambiguity. These errors previous returned EIO, but EIO connotes a complaint
from the hardware, hence the change to E2BIG and EINVAL. By the way, I am
assuming that these conditions really can be caused by user level code
accessing /dev/i2c... If not, then I would be happy to replace them with
BUG_ON() statements.
d. Delete the comment "see if last msg is a read", since (c) makes it redundant
due to the clearer diagnostic message "Final DP-MST I2C transaction was not a
read".
e. Since we're concerned about invalid i2c message parameters resulting in
invalid memory references, also guard against num <= 0. Return -EDOM in this
case, since that really would cause a problem with the mathematical domain of a
function, because the line "...num_transactions = num - 1" would result in -1
being cast into 255 for the 8 bit field num_transactions.
f. Eliminate the variable "reading", which was computed and used only once,
immediately after it was computed.
g. Be more friendly to the optimizer by using unlikely() (and likely() instead
of unlikely() in one place to reduce the number of parentheses).
h. Be more friendly to the optimizer and maybe make the code more readable by
consolidating the seven computions of "num - 1" into a new variable, "count".
I know that having two varaibles named "num" and "count" where count == num - 1
is not the greatest naming convention. Please feel free to rename. There
actually is one place toward the end of the function where "num" is used
(rather than num - 1).
h. Do the check for num - 1 > DP_REMOTE_I2C_READ_MAX_TRANSACTIONS in a manner
not susceptible to integer overflow.
I realize that this patch conflates all these different minor changes. I would
be willing to submit these changes individually or in a few smaller groups if
necessary.
By the way, the attached patch assumes is against Linux 4.3-rc5 after Dave
Airlie's patch from
http://lists.freedesktop.org/archives/dri-devel/2015-October/092465.html is
applied.
Anyhow, I hope this patch is helpful.
Adam
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=19690
Martin Peres <martin.peres(a)free.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|NEW |RESOLVED
--- Comment #1 from Martin Peres <martin.peres(a)free.fr> ---
Hi,
Freedesktop's Bugzilla instance is EOLed and open bugs are about to be migrated
to http://gitlab.freedesktop.org.
To avoid migrating out of date bugs, I am now closing all the bugs that did not
see any activity in the past year. If the issue is still happening, please
create a new bug in the relevant project at https://gitlab.freedesktop.org/drm
(use misc by default).
Sorry about the noise!
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=16083
Martin Peres <martin.peres(a)free.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|NEW |RESOLVED
--- Comment #3 from Martin Peres <martin.peres(a)free.fr> ---
Hi,
Freedesktop's Bugzilla instance is EOLed and open bugs are about to be migrated
to http://gitlab.freedesktop.org.
To avoid migrating out of date bugs, I am now closing all the bugs that did not
see any activity in the past year. If the issue is still happening, please
create a new bug in the relevant project at https://gitlab.freedesktop.org/drm
(use misc by default).
Sorry about the noise!
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=69675
Priority: medium
Bug ID: 69675
Assignee: dri-devel(a)lists.freedesktop.org
Summary: audio broken in 24Hz/24p since 3.11 (regression)
Severity: normal
Classification: Unclassified
OS: All
Reporter: pierre-bugzilla(a)ossman.eu
Hardware: Other
Status: NEW
Version: unspecified
Component: DRM/other
Product: DRI
Bug 64503 is back again, but this time it isn't a case of PEBKAC. Instead it is
commit e6e792092e816bea0797995c886fb057c91d4546 that breaks things.
With 3.10 I have just this 24p mode in Xorg:
[ 47.361] (II) RADEON(0): Modeline "1920x1080"x24.0 74.25 1920 2558 2602
2750 1080 1084 1089 1125 +hsync +vsync (27.0 kHz e)
With 3.11 I have two:
Xorg.0.log:[ 56.189] (II) RADEON(0): Modeline "1920x1080"x24.0 74.25 1920
2558 2602 2750 1080 1084 1089 1125 +hsync +vsync (27.0 kHz e)
Xorg.0.log:[ 56.189] (II) RADEON(0): Modeline "1920x1080"x24.0 74.18 1920
2558 2602 2750 1080 1084 1089 1125 +hsync +vsync (27.0 kHz e)
And although the second one gives me an image, audio is royally screwed up.
Please revert, or at least give us a knob to disable these extra modes.
--
You are receiving this mail because:
You are the assignee for the bug.