search for: encodic

Currently we restrict the number of encoders that can be linked to a connector to 3, increase it to match the maximum number of encoders that can be initialized(32). To more effiently do that lets switch from an array of encoder ids to bitmask. v2: Fixing missed return on amdgpu_dm_connector_to_encoder() Suggested-by: Ville Syrjälä <ville.syrjala at linux.intel.com> Cc: Ville Syrjälä

From: Dhinakaran Pandiyan <dhinakaran.pandiyan at intel.com> Currently we restrict the number of encoders that can be linked to a connector to 3, increase it to match the maximum number of encoders that can be initialized(32). To more effiently do that lets switch from an array of encoder ids to bitmask. Also removing the best_encoder hook from the drivers that only have one encoder per

From: Dhinakaran Pandiyan <dhinakaran.pandiyan at intel.com> Currently we restrict the number of encoders that can be linked to a connector to 3, increase it to match the maximum number of encoders that can be initialized(32). To more effiently do that lets switch from an array of encoder ids to bitmask. v2: Fixing missed return on amdgpu_dm_connector_to_encoder() Suggested-by: Ville

Currently we restrict the number of encoders that can be linked to a connector to 3, increase it to match the maximum number of encoders that can be initialized(32). To more effiently do that lets switch from an array of encoder ids to bitmask. v2: Fixing missed return on amdgpu_dm_connector_to_encoder() Suggested-by: Ville Syrjälä <ville.syrjala at linux.intel.com> Cc: Ville Syrjälä

From: Dhinakaran Pandiyan <dhinakaran.pandiyan at intel.com> Currently we restrict the number of encoders that can be linked to a connector to 3, increase it to match the maximum number of encoders that can be initialized(32). To more effiently do that lets switch from an array of encoder ids to bitmask. Also removing the best_encoder hook from the drivers that only have one encoder per

On Thu, Sep 05, 2019 at 02:09:27PM -0700, José Roberto de Souza wrote: > From: Dhinakaran Pandiyan <dhinakaran.pandiyan at intel.com> > > Currently we restrict the number of encoders that can be linked to > a connector to 3, increase it to match the maximum number of encoders > that can be initialized(32). > > To more effiently do that lets switch from an array of

It turns out that I forgot to go through and make sure that I converted all encoder callbacks to use atomic_enable/atomic_disable(), so let's go and actually do that. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Kirill A. Shutemov <kirill at shutemov.name> Fixes: 09838c4efe9a ("drm/nouveau/kms: Search for encoders' connectors properly") ---

On Fri, Feb 07, 2020 at 09:41:31AM +0100, Thomas Zimmermann wrote: > The simple-encoder helpers initialize an encoder with an empty > implementation. This covers the requirements of most of the existing > DRM drivers. A call to drm_simple_encoder_create() allocates and > initializes an encoder instance, a call to drm_simple_encoder_init() > initializes a pre-allocated instance. >

On Fri, Feb 07, 2020 at 09:41:31AM +0100, Thomas Zimmermann wrote: > The simple-encoder helpers initialize an encoder with an empty > implementation. This covers the requirements of most of the existing > DRM drivers. A call to drm_simple_encoder_create() allocates and > initializes an encoder instance, a call to drm_simple_encoder_init() > initializes a pre-allocated instance. >

Assuming that GPUs would never have even close to 32 separate video encoders is quite honestly a pretty reasonable assumption. Unfortunately we do not live in a reasonable world, as it looks like it is actually possible to find devices that will create more drm_encoder objects then this. Case in point: the ThinkPad P71's discrete GPU, which exposes 1 eDP port and 5 DP ports. On the P71,

Many DRM drivers implement an encoder with an empty implementation. This patchset adds drm_simple_encoder_init() and drm_simple_encoder_create(), which can be used by drivers instead. Except for the destroy callback, the simple encoder's implementation is empty. The patchset also converts 4 encoder instances to use the simple-encoder helpers. But there are at least 11 other drivers which can

On Tue, Sep 3, 2019 at 4:49 PM Lyude Paul <lyude at redhat.com> wrote: > > Currently, every single piece of code in amdgpu that loops through > connectors does it incorrectly and doesn't use the proper list iteration > helpers, drm_connector_list_iter_begin() and > drm_connector_list_iter_end(). Yeesh. > > So, do that. In fairness, I think the origin of this code

Thank you, Clayton. It works now! Our debugger server responds "name:J28;generic:fp;bitsize:32;encoding:uint;format:hex;gcc:60;dwarf:60". And I also set other "generic" attributes like sp, pc, ra, arg1~arg8 to related registers. I dig a little and find llvm dwarf generator uses TargetRegisterInfo::getFrameRegister() to obtain frame base, and uses

Assuming that GPUs would never have even close to 32 separate video encoders is quite honestly a pretty reasonable assumption. Unfortunately we do not live in a reasonable world, as it looks like it is actually possible to find devices that will create more drm_encoder objects then this. Case in point: the ThinkPad P71's discrete GPU, which exposes 1 eDP port and 5 DP ports. On the P71,

Currently, every single piece of code in amdgpu that loops through connectors does it incorrectly and doesn't use the proper list iteration helpers, drm_connector_list_iter_begin() and drm_connector_list_iter_end(). Yeesh. So, do that. Cc: Juston Li <juston.li at intel.com> Cc: Imre Deak <imre.deak at intel.com> Cc: Ville Syrjälä <ville.syrjala at linux.intel.com> Cc: Harry

I do the following to init flac: encoder = FLAC__stream_encoder_new(); e = FLAC__stream_encoder_set_do_mid_side_stereo (encoder, numChannels == 2); e = FLAC__stream_encoder_set_loose_mid_side_stereo (encoder, numChannels == 2); e = FLAC__stream_encoder_set_channels (encoder, numChannels); e = FLAC__stream_encoder_set_bits_per_sample (encoder, jmin (24,

No functional changes, just change the function names to match the callbacks they provide. Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 33 ++++++++++++------------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c index

On Thu, Feb 15, 2018 at 11:19 AM, Kevin Ushey <kevinushey at gmail.com> wrote: > I suspect your UTF-8 string is being stripped of its encoding before > write, and so assumed to be in the system native encoding, and then > re-encoded as UTF-8 when written to the file. You can see something > similar with: > > > tmp <- '?' > > tmp <- iconv(tmp,

I am trying to install vorbis-tools 1.0.1 onto my mac os 10.3.5 I installed the relevant libraries through fink (http://fink.sourceforge.net) - libao2, libvorbis, libogg my configure command was this: ./configure -with-ogg=/sw --with-ao=/sw --without-flac --without-speex I received no errors from configure except to let me know that oggenc would not have flac support and that ogg123 would

hi I have some questions about re-encoding existing FLAC files to FLAC 1.2.0.: - can older 1.1.x FLAC files be re-encoded to FLAC 1.2.0 by using the FLAC 1.2.0 encoder? - can FLAC files encoded with the FLAC Flake SVN encoder (or any other 'unofficial' FLAC encoder) be re-encoded by using the FLAC 1.2.0 encoder? thx in advance! -------------- next part -------------- An HTML attachment