search for: source_string

...aybe a function which gives acces to the comments, and then the id3 code could go where it is needed and not in the format). play-becomes-control-default.patch This patch reworks ogg123.c. It moves the play function into the function control_default which takes in a playlist instead of one source_string. This patch also removes the convbuffer global and allocated it with malloc in control_default(). It looks like a big patch but that's just because the play() function is now indented and restructured. Not much real changes here. add-remote-interface.patch This patch adds the remote in...

...39;d like to use the --delete option in the command above. However, I wake up in a cold sweat worrying about supplying the empty string for source_dir, and thus removing souce_dir, and all it's siblings on target_machine. Now I realize, I can just be extra careful that the variable pointing to source_string is never empty, but I would like to have other fail safe mechanisms in place. I hope I have been sufficiently specific to elicit some suggestions. I guess I am looking for the software equivalent of lots of padlocks on the apartment door. Thanks, Ted Gilchrist -- "Speech, not just for hum...

If CONFIG_DRM_NOUVEAU=y,the following errors are seen while building crc.h. In file included from /scratch/linux/drivers/gpu/drm/nouveau/nouveau_display.c:47: /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ?nv50_head_crc_late_register?: /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h:109:47: error: parameter name omitted static inline int

...als. #7 0x08052690 in flac_init (source=0x805aa60, ogg123_opts=0x8059d60, audio_fmt=0xbffff3e0, callbacks=0xbffff408, callback_arg=0x407ed008) at ../../ogg123/flac_format.c:181 decoder = (decoder_t *) 0x805b990 private = (flac_private_t *) 0x805b9d0 ret = -1073745000 #8 0x0804fec0 in play (source_string=0x805b8d0 "crash.flac") at ../../ogg123/ogg123.c:464 transport = (transport_t *) 0x80586c0 format = (format_t *) 0x8058820 source = (data_source_t *) 0x805aa60 decoder = (decoder_t *) 0x10000000 decoder_callbacks = {printf_error = 0x804d0d8 <decoder_buffered_error_callback>,...

Hi, I actually already sent a patch for this: https://patchwork.freedesktop.org/patch/378202/ I'm guessing it hasn't gotten picked up upstream yet? On Mon, 2020-07-27 at 12:00 +0800, Peng Wu wrote: > If CONFIG_DRM_NOUVEAU=y,the following errors > are seen while building crc.h. > > In file included from > /scratch/linux/drivers/gpu/drm/nouveau/nouveau_display.c:47: >

...h_and_process_packet () from /usr/radio//lib/libvorbisfile.so.3 #9 0x4001c235 in ov_read () from /usr/radio//lib/libvorbisfile.so.3 #10 0x0804f329 in ovf_read (decoder=0x8079658, ptr=0x80551a0, nbytes=1280, eos=0xbffffc04, audio_fmt=0xbffffc10) at oggvorbis_format.c:139 #11 0x0804ed48 in play (source_string=0x8055b60 "http://localhost:443/radio-bro-gwened-ori.ogg") at ogg123.c:529 #12 0x0804e9b3 in main (argc=9, argv=0xbffffd74) at ogg123.c:393 <p>and this morning, it was stuck here: #0 0x401f55d4 in __pthread_sigsuspend () from /lib/libpthread.so.0 #1 0xbf7ff6e0 in ?? () #2 0x401f...

Greetings one and all; I'm not subscribed to this list so I'm first sending this message to verify that mails from me make it through, and then later I'll send the juicy messages with patches. Also, the address I'm using is IPv6-only and doesn't often work, so drop me from any replies and I'll catch the archives, or drop only the hostname part to get an IPv4 address that

This introduces support for CRC readback on gf119+, using the documentation generously provided to us by Nvidia: https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed through a single set of "outp" sources: outp-active/auto for a CRC of the scanout region, outp-complete for a CRC of both

This introduces support for CRC readback on gf119+, using the documentation generously provided to us by Nvidia: https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed through a single set of "outp" sources: outp-active/auto for a CRC of the scanout region, outp-complete for a CRC of both

This introduces support for CRC readback on gf119+, using the documentation generously provided to us by Nvidia: https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed through a single set of "outp" sources: outp-active/auto for a CRC of the scanout region, outp-complete for a CRC of both

This introduces support for CRC readback on gf119+, using the documentation generously provided to us by Nvidia: https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed through a single set of "outp" sources: outp-active/auto for a CRC of the scanout region, outp-complete for a CRC of both

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests that we'll be sending in just a short bit. This additionally adds a feature that Ville Syrj?l? came up with: vblank works. Basically, this is just a generic DRM

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests that we'll be sending in just a short bit. This additionally adds a feature that Ville Syrj?l? came up with: vblank works. Basically, this is just a generic DRM

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up

Hello, while I debugged an issue in the imx-lcdc driver I was constantly irritated about struct drm_device pointer variables being named "dev" because with that name I usually expect a struct device pointer. I think there is a big benefit when these are all renamed to "drm_dev". I have no strong preference here though, so "drmdev" or "drm" are fine for me,

Hello, while I debugged an issue in the imx-lcdc driver I was constantly irritated about struct drm_device pointer variables being named "dev" because with that name I usually expect a struct device pointer. I think there is a big benefit when these are all renamed to "drm_dev". I have no strong preference here though, so "drmdev" or "drm" are fine for me,