high contrast terminal icon does not fit in
by Matthew Miller
I just updated to the F30 beta. I'm pretty sensitive to color, so I use the
high-contrast black and white theme. In F29 and previous, this resulted in a
matching icon in the dash (well, dock, as I am using that extension).
However, in F30, I get a high-res icon which does not match.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
5 years
"Basic graphics mode" feature and criterion discussion
by Adam Williamson
Hi folks!
So at last week's Fedora 30 Beta Go/No-Go meeting, it was decided that
the Basic release criterion:
"Boot menu contents
The boot menu for all supported installer and live images should
include an entry which causes both installation and the installed
system to use a generic, highly compatible video driver (such as
'vesa'). This mechanism should work correctly, launching the installer
or desktop and attempting to use the generic driver."
should no longer apply to Beta - i.e. that it should no longer be a
Basic or Beta criterion.
The justification for this is, I hope I am correctly representing all
views here (please say so if not), that this mechanism is both less
necessary (due to a general reduction in the amount of 'weird' graphics
hardware out there, and general improvement in the reliability and
coverage of the major drivers for the major graphics hardware
manufacturers) and inherently less likely to work (due to the general
trend of work on kernel modesetting and Wayland) than it used to be.
For context, it is worth noting that the *feature* predates the
introduction of both kernel modesetting *and* Wayland to Fedora. What
the feature initially did was tell anaconda to write an X config file
specifying the 'vesa' driver (instead of working out the correct
'native' driver for the adapter and writing a config file specifying
that). After KMS was introduced in Fedora 10, the mechanism was tweaked
to also pass the 'nomodeset' kernel parameter to disable KMS. Around
2012 (https://bugzilla.redhat.com/show_bug.cgi?id=858270) we noticed
that the X config file mechanism was a bit superfluous as 'nomodeset'
alone could basically be relied on to force some sort of 'fallback
mechanism', and so the feature was simplified to *only* specify the
'nomodeset' kernel parameter (this is all it does now).
The *criterion* dates to 2010, in the Fedora 15 release cycle: it
appears in the Fedora 15 Alpha criteria but not the Fedora 14 Alpha
criteria. It was added on 2010-08-16:
https://fedoraproject.org/w/index.php?title=Fedora_15_Alpha_Release_Crite...
The group at the meeting did not, however, make any further decisions,
so this leaves us with some open questions:
0) Do we generally agree with the decision made at the meeting? If
anyone (especially a subject matter expert) strongly believes the
decision was wrong and this should still be a Basic/Beta requirement,
please say so.
1) Should the criterion be modified somehow, but some requirement in
relation to some kind of fallback graphical mode be kept at Basic or
Beta?
2) Should the criterion be moved to Final, unchanged or changed
somehow?
3) Should the requirement just basically be dropped entirely as no
longer useful?
4) (This one mainly for ajax and airlied) to what extent does the
concept of a 'fallback option' for our supported desktop environments
and graphical servers still actually make sense? Could a different
implementation of the same basic idea be envisaged, and would it be
useful? If so, should we do that, and what would be the consequences
for the criteria?
I realize this is quite a big and fuzzy topic, but I'm hoping the
responses to this mail will clarify our path :) So if you have any kind
of useful information or strong opinions on the general area here,
please do contribute them, and hopefully a clearer way forward will
emerge.
Thanks everyone!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
5 years
Audio downmixing and normalization
by Michael Cronenworth
Updating my audio collection has introduced a few new issues into the wrench. Adding
multi-channel audio has proven to be a little problematic.
- ReplainGain support for multi-channel audio is lacking in Fedora. I've poked one
upstream about it. [1]
- Downmixing multi-channel audio to stereo results in poor output out of the box
with Fedora defaults. The rear channels are basically dropped. Attempting to use a
PulseAudio virtual surround sink results in muddy, soft audio. Using a remap sink to
send rear channels to their respective front channels results in clear, soft audio.
No normalization appears to happen.
My multi-channel setup: Kodi -> HDMI -> 5.1 receiver -> speakers
My stereo setup: Rhythmbox -> analog jack -> speakers
FFmpeg and other audio processing libraries and players (including Kodi) have proper
downmixing that includes normalization with their defaults. Even my Pixel 3 appears
to do it right if I send a 5.1 track to it and play it out of its stereo speakers
when I played a 5.1 track and its stereo duplicate track back-to-back. I find it a
little disappointing that PulseAudio isn't doing it and would love to fix it.
Who would be the best candidate to go after supporting a proper downmix +
normalization path? PulseAudio? Gnome? Rhythmbox?
If you haven't experienced a multi-channel audio track I highly recommend it.
Thanks,
Michael
[1] https://github.com/xiph/flac/issues/96
5 years
