similar to: Well done on 4.8!

Colin Walters (1): autogen.sh: Implement GNOME Build API Dylan Aïssi (1): Fix typo: Initalizing --> Initializing Emil Velikov (2): autogen.sh: use quoted string variables xf86-video-r128: remove the GlxSetVisualConfigs stub and friends Helmut Grohne (1): Fix for cross build failure Kevin Brace (31): Move the location where R128PreInitGamma is called

This release is mainly meant deal with 2 urgent build failure issues reported by users. If your distribution is using Version 6.11.0, please replace it with this version as soon as possible. There is very little change in the functionality compared to the previous release, but I did rewrite hard to maintain and very awkwardly written XAA / EXA initialization code. It is always possible that I can

Adam Jackson (1): Adapt Block/WakeupHandler signature for ABI 23 Connor Behan (1): Remove gatos advertisement Kevin Brace (1): xextproto 7.1 support update to the source code Matt Turner (1): xf86-video-r128 6.10.2 git tag: xf86-video-r128-6.10.2 https://xorg.freedesktop.org/archive/individual/driver/xf86-video-r128-6.10.2.tar.bz2 MD5: 905758eb0711bf7151c4f6c435757426

Connor Behan (32): Drop dependence on xf86PciInfo.h Do not disable gouraud shading for a render op Only declare PCITAG if we need it Remove overuse of COMPOSITE_SETUP() Fix ScreenInit with noAccel Port to RandR Only enable CRTCs for DPMSModeOn Map and unmap the MMIO better Split up output register functions Move display enabling code to

Connor Behan (3): Really fix bitmasks for DDC Assume CRT in the absence of other monitors Bump to version 6.10.1 git tag: xf86-video-r128-6.10.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-r128-6.10.1.tar.bz2 MD5: 770c2342141874f8a81a95ecd1839746 xf86-video-r128-6.10.1.tar.bz2 SHA1: 25559ee795b7f417770086a53d9acdfaad8423da xf86-video-r128-6.10.1.tar.bz2

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Subject: [ANNOUNCE] xf86-video-r128 6.8.0 To: xorg-announce at lists.freedesktop.org Dave Airlie (9): r128: fix bios size setting for pciaccess George Sapountzis (8): drop radeon, theatre (build system). drop radeon, theatre drop AtomBios and pcidb drop ati wrapper drop mach64 (build system) drop mach64

Ian Nartowicz wrote: > I use it :) To optionally allow adjustment of tracks containing different > types of gain tag to a similar overall loudness. Admittedly this isn't > common. Files using the original replaygain algorithm with a reference > loudness of 83dB are now very rare, but R128 tags are starting to show up > (eg. in Opus) and these play at a significantly

>The use of R128 also raises the question about "REPLAYGAIN_REFERENCE_LOUDNESS" >tag. Currently flac/metaflac writes "REPLAYGAIN_REFERENCE_LOUDNESS=89.0 dB" >but doesn't use it when decoding (it seems that nothing uses this tag). >R128 defines reference level differently, so this tag makes little sense for >it. IMHO it's better not to write this tag when

As far as I know, R128 as ReplayGain isn't really considered final yet (see http://wiki.hydrogenaud.io/index.php?title=ReplayGain_2.0_specification for example), so it would probably be a bit early to update this in the FLAC source. op 16-06-14 10:15, Olav Sunde schreef: > I mention metaflac because there are a few shell scripts that > use it to write RG tags in a flac music

I mention metaflac because there are a few shell scripts that use it to write RG tags in a flac music library on Linux. With support for Ebu R128 gain in metaflac (the calculation according to specification, not an external program) it would be easy to use, just change the cmd line for metaflac in the script. Now that metaflac supports sample rates higher than 48kHz this would be a good thing in

Quick update - though not mentioned on the mailing lists anywhere until now, it looks like yesterday sometime, someone posted a "test suite" of datafiles to play with on the main page of www.theora.org ...but after all this time, I seem to have developed a problem with my Theora Alpha 1 build. First, somehow there appears to be a "/opt/kde/lib/libartsc.so" that gets added to

On Wed, Feb 22, 2012 at 07:00:55PM -0800, Jakob Stoklund Olesen wrote: > > On Feb 22, 2012, at 12:01 PM, Tom Stellard wrote: > > > Hi, > > > > I have two register classes A and B, where A contains a subset of the > > registers in B: > > > > A = [R0, R1, R2, ... R128] > > > > B = [RO, R1, R2, ... R128, > > T0, T1, T2, ... T128]

Hello, I am trying to upgrade dovecot from 1.0.7 (the dovecot verison in base repo) to 1.2. The installation of .rpm got from atrpms.net aborted with a dependency error : error: Failed dependencies: libpq.so.5()(64bit) is needed by dovecot-1.2.16-1_114.el5.x86_64 This is strange because the libraries are there : yum list libpq* Installed Packages libpqxx.x86_64 2.6.9-3.el5.rf installed

Hi, I have two register classes A and B, where A contains a subset of the registers in B: A = [R0, R1, R2, ... R128] B = [RO, R1, R2, ... R128, T0, T1, T2, ... T128] I am using the Greedy Register Allocator, and I would expect the register allocator to eliminate this copy: %vreg0<def> = COPY %vreg1; B:%vreg0 A:%vreg1 but instead I end up with %R0<def> = COPY %R1 Is there

hey guys, One of our developers DESTROYED both yum and rpm on one of the development machines with an rm command. And guess who's lucky enough to get to fix this mess? *raises hand* So I hope y'all don't mind me turning to you once again for some advice. You've been wonderful in the past. Pavlov's dogs as they say. At any rate, I've managed to fix rpm (yay) by copying

Non-KMS drivers store state in struct drm_driver. This bloats the structure for KMS drivers and prevents it from being declared with 'static const' qualifiers. Moving the non-KMS state into a separate data structure resolves this. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/drm_drv.c | 4 ++++ drivers/gpu/drm/i810/i810_drv.c | 4

On Feb 22, 2012, at 12:01 PM, Tom Stellard wrote: > Hi, > > I have two register classes A and B, where A contains a subset of the > registers in B: > > A = [R0, R1, R2, ... R128] > > B = [RO, R1, R2, ... R128, > T0, T1, T2, ... T128] > > I am using the Greedy Register Allocator, and I would expect the register > allocator to eliminate this copy: >

Olav Sunde wrote: > has anyone looked at adding R128gain code to metaflac so we can select > to use this calculation for RP tags rather than replay gain? Why metaflac only? flac is also able to calculate RG values. And, as far as I can see R128GAIN (http://r128gain.sourceforge.net/) is a standalone app, not a library. So probably it would be difficult to reuse its code in flac/metaflac.

On Tue, Feb 25, 2020 at 10:59 AM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Non-KMS drivers store state in struct drm_driver. This bloats the > structure for KMS drivers and prevents it from being declared with > 'static const' qualifiers. Moving the non-KMS state into a separate > data structure resolves this. > > Signed-off-by: Thomas Zimmermann

>b) According to http://wiki.xiph.org/OggOpus#Comment_Header >there should be no REPLAYGAIN_*** tags in Opus files; Opus uses >R128_TRACK_GAIN tag. If some audio player reads Opus tags then it should >be aware of the difference between ReplayGain and R128. But this doesn't >require REPLAYGAIN_REFERENCE_LOUDNESS tag. > > The Opus replaygain spec is fundamentally broken, so