Nabble - dxr3-devel

Re: page allocation failure when starting VDR

2009-12-08T12:55:16Z

Hi Jan,

On Tue, Dec 08, 2009 at 11:17:46AM +0100, Jan Willies wrote:
> Hi,
>
> Sometimes I get a page allocation failure when starting vdr.
>
> kernel-2.6.32
> em8300-0.18.0-rc1
> vdr-plugin-dxr3-git
> vdr-1.6.1
>
(...)
>
> I have vdr still open (and running) in gdb, so if I can squeeze some
> debug infos out there, just tell me what to do.

My guess is that there is a leak of DMA-able memory somewhere in the
em8300 driver...

Has your system been on for long?
Has your DXR3/H+ board been initiaized many times?
Did this problem happen with older releases of linux and em8300?
Are you able to reproduce the problem at will?

> And, I can't rmmod the em8300/adv717x modules because they are "in use",
> meaning I have to reboot the pc. Is there a way to avoid that?

Fixing the bug would help, certainly. ;-)
Apart from fixing the bug, I'm afraid that rebooting is the only
solution...

Cheers,

Nicolas

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

page allocation failure when starting VDR

2009-12-08T02:17:46Z

Hi,

Sometimes I get a page allocation failure when starting vdr.

kernel-2.6.32
em8300-0.18.0-rc1
vdr-plugin-dxr3-git
vdr-1.6.1

vdr: page allocation failure. order:5, mode:0x8020
Pid: 7164, comm: vdr Not tainted 2.6.32 #2
Call Trace:
[<c13313e9>] ? printk+0x18/0x1f
[<c104f2fd>] __alloc_pages_nodemask+0x43b/0x52c
[<c100645b>] dma_generic_alloc_coherent+0x57/0xbc
[<d0956f9d>] em8300_fifo_init+0x23b/0x2ce [em8300]
[<c1006404>] ? dma_generic_alloc_coherent+0x0/0xbc
[<d095952d>] em8300_ioctl_init+0x141/0x1cc [em8300]
[<d095991f>] em8300_control_ioctl+0x367/0x988 [em8300]
[<c106cce6>] ? do_sync_read+0xba/0xea
[<d0954536>] em8300_io_ioctl+0x2b/0x56 [em8300]
[<d095450b>] ? em8300_io_ioctl+0x0/0x56 [em8300]
[<c10778e0>] vfs_ioctl+0x50/0x52
[<c1077e6a>] do_vfs_ioctl+0x69/0x53f
[<c107f72c>] ? mntput_no_expire+0x16/0x6b
[<c106def3>] ? __fput+0x16e/0x1c7
[<c106df60>] ? fput+0x14/0x1d
[<c1078373>] sys_ioctl+0x33/0x4f
[<c1002b48>] sysenter_do_call+0x12/0x26
Mem-Info:
DMA per-cpu:
CPU 0: hi: 0, btch: 1 usd: 0
Normal per-cpu:
CPU 0: hi: 90, btch: 15 usd: 78
active_anon:9294 inactive_anon:9330 isolated_anon:0
active_file:17856 inactive_file:18853 isolated_file:0
unevictable:0 dirty:101 writeback:27 unstable:0
free:2643 slab_reclaimable:1876 slab_unreclaimable:1859
mapped:3547 shmem:1 pagetables:245 bounce:0
DMA free:1808kB min:120kB low:148kB high:180kB active_anon:1448kB
inactive_anon:1456kB active_file:3236kB inactive_file:7232kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15804kB
mlocked:0kB dirty:32kB writeback:0kB mapped:732kB shmem:0kB
slab_reclaimable:364kB slab_unreclaimable:288kB kernel_stack:72kB
pagetables:12kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 238 238
Normal free:8764kB min:1912kB low:2388kB high:2868kB active_anon:35728kB
inactive_anon:35864kB active_file:68188kB inactive_file:68180kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:243776kB
mlocked:0kB dirty:372kB writeback:108kB mapped:13456kB shmem:4kB
slab_reclaimable:7140kB slab_unreclaimable:7148kB kernel_stack:976kB
pagetables:968kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
DMA: 274*4kB 19*8kB 11*16kB 12*32kB 0*64kB 0*128kB 0*256kB 0*512kB
0*1024kB 0*2048kB 0*4096kB = 1808kB
Normal: 823*4kB 260*8kB 148*16kB 26*32kB 1*64kB 1*128kB 0*256kB 0*512kB
0*1024kB 0*2048kB 0*4096kB = 8764kB
41875 total pagecache pages
5165 pages in swap cache
Swap cache stats: add 189980, delete 184815, find 232444/261072
Free swap = 427524kB
Total swap = 498004kB
65520 pages RAM
1855 pages reserved
42255 pages shared
34146 pages non-shared
em8300-0: Microcode version 0x29 loaded
em8300-0: Analog audio enabled
em8300-0: Digital PCM audio enabled
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<c1332497>] __down+0x1f/0x68
*pde = 00000000
Oops: 0002 [#1]
last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:02:05.0/zoom
Modules linked in: lirc_serial lirc_dev xts gf128mul ext2 tda10021
snd_mpu401_uart 8250_pnp snd_rawmidi 8250 serial_core dvb_pll mt352
budget_av saa7146_vv stv0299 videodev videobuf_dma_sg snd_seq_oss
snd_seq_midi_event videobuf_core snd_seq b2c2_flexcop_pci snd_seq_device
budget_core saa7146 ttpci_eeprom b2c2_flexcop cx24123 cx24113 s5h1420
uhci_hcd i2c_i801 evdev fan button aes_i586 aes_generic fuse dvb_core
em8300 adv717x i2c_algo_bit snd_ac97_codec snd_pcm_oss snd_pcm snd_timer
snd_page_alloc snd_mixer_oss snd soundcore ac97_bus e100

Pid: 7176, comm: vdr Not tainted (2.6.32 #2) SCENIC xB
EIP: 0060:[<c1332497>] EFLAGS: 00010092 CPU: 0
EIP is at __down+0x1f/0x68
EAX: c8b48d10 EBX: c4f0c760 ECX: c4f53f00 EDX: 00000000
ESI: c8b48d0c EDI: 00000002 EBP: c4f53f14 ESP: c4f53f00
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process vdr (pid: 7176, ti=c4f52000 task=c4f0c760 task.ti=c4f52000)
Stack:
c8b48d10 00000000 cf35369c c4f53f20 00000296 c4f53f20 c1032982 c8b48cc0
<0> c4f53f3c d0956c05 00002480 082a5630 00001200 082a5630 cf044000 c4f53f4c
<0> d0955c5b 00000000 c4dbe580 c4f53f64 d09545f2 c4f53f98 c4dbe580 00001200
Call Trace:
[<c1032982>] ? down+0x1c/0x2a
[<d0956c05>] ? em8300_fifo_write+0x1a/0x3f [em8300]
[<d0955c5b>] ? em8300_audio_write+0x3a/0x40 [em8300]
[<d09545f2>] ? em8300_io_write+0x91/0x99 [em8300]
[<c106d630>] ? vfs_write+0x8c/0x177
[<d0954561>] ? em8300_io_write+0x0/0x99 [em8300]
[<c106d7bf>] ? sys_write+0x3d/0x64
[<c1002b48>] ? sysenter_do_call+0x12/0x26
Code: 89 42 04 89 10 b8 fc ff ff ff eb d2 55 89 e5 53 83 ec 10 8b 1d 8c
ea 42 c1 8b 50 08 8d 4d ec 89 48 08 83 c0 04 89 45 ec 89 55 f0 <89> 0a
89 5d f4 c7 45 f8 00 00 00 00 b8 ff ff ff 7f eb 04 85 c0
EIP: [<c1332497>] __down+0x1f/0x68 SS:ESP 0068:c4f53f00
CR2: 0000000000000000
---[ end trace 6793fd87635937fe ]---
i2c i2c-0: sendbytes: NAK bailout.

###########################################################################

or this one:

Sigma Designs EM8300 0000:02:05.0: PCI INT A disabled
Sigma Designs EM8300 0000:02:05.0: PCI INT A -> GSI 17 (level, low) ->
IRQ 17
em8300-0: EM8300 8300 (rev 2)
bus: 2, devfn: 40, irq: 17,
memory: 0xf4100000.
em8300-0: mapped-memory at 0xd1a00000
em8300-0: using MTRR
IRQ 17/em8300: IRQF_DISABLED is not guaranteed on shared IRQs
em8300-0: unable to identify model...
em8300-0: Chip revision: 2
i2c i2c-1: sendbytes: NAK bailout.
adv717x.o: ADV7175A rev. 0 chip probed
unable to register OSS PCM device 0:0
vdr: page allocation failure. order:5, mode:0x8020
Pid: 4279, comm: vdr Not tainted 2.6.32 #2
Call Trace:
[<c13313e9>] ? printk+0x18/0x1f
[<c104f2fd>] __alloc_pages_nodemask+0x43b/0x52c
[<c100645b>] dma_generic_alloc_coherent+0x57/0xbc
[<d19abfad>] em8300_fifo_init+0x23b/0x2ce [em8300]
[<d19abc99>] ? em8300_fifo_alloc+0x13/0x29 [em8300]
[<c1006404>] ? dma_generic_alloc_coherent+0x0/0xbc
[<d19ae507>] em8300_ioctl_init+0x10b/0x1cc [em8300]
[<d19ae92f>] em8300_control_ioctl+0x367/0x988 [em8300]
[<c106cce6>] ? do_sync_read+0xba/0xea
[<d19a9536>] em8300_io_ioctl+0x2b/0x56 [em8300]
[<d19a950b>] ? em8300_io_ioctl+0x0/0x56 [em8300]
[<c10778e0>] vfs_ioctl+0x50/0x52
[<c1077e6a>] do_vfs_ioctl+0x69/0x53f
[<c107f72c>] ? mntput_no_expire+0x16/0x6b
[<c106def3>] ? __fput+0x16e/0x1c7
[<c106df60>] ? fput+0x14/0x1d
[<c1078373>] sys_ioctl+0x33/0x4f
[<c1002b48>] sysenter_do_call+0x12/0x26
Mem-Info:
DMA per-cpu:
CPU 0: hi: 0, btch: 1 usd: 0
Normal per-cpu:
CPU 0: hi: 90, btch: 15 usd: 35
active_anon:16057 inactive_anon:16114 isolated_anon:0
active_file:11433 inactive_file:13651 isolated_file:0
unevictable:0 dirty:27 writeback:0 unstable:0
free:1320 slab_reclaimable:1158 slab_unreclaimable:2053
mapped:8868 shmem:29 pagetables:239 bounce:0
DMA free:1688kB min:120kB low:148kB high:180kB active_anon:1336kB
inactive_anon:1392kB active_file:816kB inactive_file:10016kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15804kB
mlocked:0kB dirty:0kB writeback:0kB mapped:1176kB shmem:0kB
slab_reclaimable:8kB slab_unreclaimable:608kB kernel_stack:40kB
pagetables:12kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 238 238
Normal free:3592kB min:1912kB low:2388kB high:2868kB active_anon:62892kB
inactive_anon:63064kB active_file:44916kB inactive_file:44588kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:243776kB
mlocked:0kB dirty:108kB writeback:0kB mapped:34296kB shmem:116kB
slab_reclaimable:4624kB slab_unreclaimable:7604kB kernel_stack:1000kB
pagetables:944kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
DMA: 272*4kB 5*8kB 25*16kB 5*32kB 0*64kB 0*128kB 0*256kB 0*512kB
0*1024kB 0*2048kB 0*4096kB = 1688kB
Normal: 580*4kB 45*8kB 35*16kB 5*32kB 3*64kB 0*128kB 0*256kB 0*512kB
0*1024kB 0*2048kB 0*4096kB = 3592kB
25656 total pagecache pages
535 pages in swap cache
Swap cache stats: add 1092, delete 557, find 400/422
Free swap = 494332kB
Total swap = 498004kB
65520 pages RAM
1855 pages reserved
40912 pages shared
42246 pages non-shared
vdr: page allocation failure. order:5, mode:0x8020
Pid: 4279, comm: vdr Not tainted 2.6.32 #2
Call Trace:
[<c13313e9>] ? printk+0x18/0x1f
[<c104f2fd>] __alloc_pages_nodemask+0x43b/0x52c
[<c100645b>] dma_generic_alloc_coherent+0x57/0xbc
[<d19abfad>] em8300_fifo_init+0x23b/0x2ce [em8300]
[<d19abc99>] ? em8300_fifo_alloc+0x13/0x29 [em8300]
[<c1006404>] ? dma_generic_alloc_coherent+0x0/0xbc
[<d19ae53d>] em8300_ioctl_init+0x141/0x1cc [em8300]
[<d19ae92f>] em8300_control_ioctl+0x367/0x988 [em8300]
[<c106cce6>] ? do_sync_read+0xba/0xea
[<d19a9536>] em8300_io_ioctl+0x2b/0x56 [em8300]
[<d19a950b>] ? em8300_io_ioctl+0x0/0x56 [em8300]
[<c10778e0>] vfs_ioctl+0x50/0x52
[<c1077e6a>] do_vfs_ioctl+0x69/0x53f
[<c107f72c>] ? mntput_no_expire+0x16/0x6b
[<c106def3>] ? __fput+0x16e/0x1c7
[<c106df60>] ? fput+0x14/0x1d
[<c1078373>] sys_ioctl+0x33/0x4f
[<c1002b48>] sysenter_do_call+0x12/0x26
Mem-Info:
DMA per-cpu:
CPU 0: hi: 0, btch: 1 usd: 0
Normal per-cpu:
CPU 0: hi: 90, btch: 15 usd: 53
active_anon:16043 inactive_anon:16128 isolated_anon:0
active_file:11395 inactive_file:13676 isolated_file:0
unevictable:0 dirty:30 writeback:14 unstable:0
free:1320 slab_reclaimable:1158 slab_unreclaimable:2053
mapped:8863 shmem:29 pagetables:239 bounce:0
DMA free:1688kB min:120kB low:148kB high:180kB active_anon:1336kB
inactive_anon:1392kB active_file:816kB inactive_file:10016kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15804kB
mlocked:0kB dirty:0kB writeback:0kB mapped:1176kB shmem:0kB
slab_reclaimable:8kB slab_unreclaimable:608kB kernel_stack:40kB
pagetables:12kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 238 238
Normal free:3592kB min:1912kB low:2388kB high:2868kB active_anon:62836kB
inactive_anon:63120kB active_file:44764kB inactive_file:44688kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:243776kB
mlocked:0kB dirty:120kB writeback:56kB mapped:34276kB shmem:116kB
slab_reclaimable:4624kB slab_unreclaimable:7604kB kernel_stack:1000kB
pagetables:944kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:73 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
DMA: 272*4kB 5*8kB 25*16kB 5*32kB 0*64kB 0*128kB 0*256kB 0*512kB
0*1024kB 0*2048kB 0*4096kB = 1688kB
Normal: 580*4kB 45*8kB 35*16kB 5*32kB 3*64kB 0*128kB 0*256kB 0*512kB
0*1024kB 0*2048kB 0*4096kB = 3592kB
25652 total pagecache pages
549 pages in swap cache
Swap cache stats: add 1106, delete 557, find 400/422
Free swap = 494276kB
Total swap = 498004kB
65520 pages RAM
1855 pages reserved
40894 pages shared
42244 pages non-shared
em8300-0: Microcode version 0x29 loaded
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<c1332497>] __down+0x1f/0x68
*pde = 00000000
Oops: 0002 [#1]
last sysfs file: /sys/module/snd_seq_oss/initstate
Modules linked in: em8300 adv717x lirc_serial lirc_dev xts gf128mul ext2
tda10021 snd_mpu401_uart 8250_pnp snd_rawmidi 8250 serial_core dvb_pll
mt352 budget_av saa7146_vv stv0299 videodev videobuf_dma_sg
videobuf_core b2c2_flexcop_pci snd_seq_oss snd_seq_midi_event
budget_core snd_seq snd_seq_device b2c2_flexcop cx24123 saa7146
ttpci_eeprom cx24113 s5h1420 uhci_hcd i2c_i801 evdev fan button aes_i586
aes_generic fuse dvb_core i2c_algo_bit snd_ac97_codec snd_pcm_oss
snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd soundcore ac97_bus
e100 [last unloaded: adv717x]

Pid: 4279, comm: vdr Not tainted (2.6.32 #2) SCENIC xB
EIP: 0060:[<c1332497>] EFLAGS: 00010096 CPU: 0
EIP is at __down+0x1f/0x68
EAX: cf0c2230 EBX: c223ac40 ECX: c94e7ec8 EDX: 00000000
ESI: cf0c222c EDI: 00000001 EBP: c94e7edc ESP: c94e7ec8
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process vdr (pid: 4279, ti=c94e6000 task=c223ac40 task.ti=c94e6000)
Stack:
cf0c2230 00000000 c94e7f5c 00000000 00000286 c94e7ee8 c1032982 cf0c21e0
<0> c94e7f04 d19abbd6 c098d000 b7981220 000049a9 c098d000 c098d000 c94e7f4c
<0> d19ac480 00000000 c10778e0 ccc821d0 000000c7 c94e7f60 c1033462 000049a9
Call Trace:
[<c1032982>] ? down+0x1c/0x2a
[<d19abbd6>] ? em8300_fifo_writeblocking+0x1a/0x3f [em8300]
[<d19ac480>] ? em8300_video_write+0x183/0x1e7 [em8300]
[<c10778e0>] ? vfs_ioctl+0x50/0x52
[<c1033462>] ? T.279+0xe/0x196
[<d0be16f9>] ? ttpci_budget_init+0xba/0x4e2 [budget_core]
[<d19a95b0>] ? em8300_io_write+0x4f/0x99 [em8300]
[<c106d630>] ? vfs_write+0x8c/0x177
[<d19a9561>] ? em8300_io_write+0x0/0x99 [em8300]
[<c106d7bf>] ? sys_write+0x3d/0x64
[<c1002b48>] ? sysenter_do_call+0x12/0x26
Code: 89 42 04 89 10 b8 fc ff ff ff eb d2 55 89 e5 53 83 ec 10 8b 1d 8c
ea 42 c1 8b 50 08 8d 4d ec 89 48 08 83 c0 04 89 45 ec 89 55 f0 <89> 0a
89 5d f4 c7 45 f8 00 00 00 00 b8 ff ff ff 7f eb 04 85 c0
EIP: [<c1332497>] __down+0x1f/0x68 SS:ESP 0068:c94e7ec8
CR2: 0000000000000000
---[ end trace 2d71bf4c0eb0bd0d ]---

I have vdr still open (and running) in gdb, so if I can squeeze some
debug infos out there, just tell me what to do.

And, I can't rmmod the em8300/adv717x modules because they are "in use",
meaning I have to reboot the pc. Is there a way to avoid that?

- jan

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

Re: [PULL REQUEST] i2c changes

2009-12-08T02:15:55Z

Hi Nicolas,

2009/12/6 Nicolas Boullis <nboullis@...>:

> Hi Christian,
>
> On Sun, Dec 06, 2009 at 06:05:33PM +0100, Christian Gmeiner wrote:
>>
>> All you told is correct, but my patch does this:
>>
>> em8300_i2c_init1:
>> Init the two i2c buses and get EEPROM device.
>>
>> em8300_i2c_init2:
>> Based on the model detection (EEPROM) load needed modules and setup
>> em->encoder.
>>
>> Now you need to have a look at the context where they get called.
>>
> (...)
>>
>> So there is no breaking change for auto detection. The old behavior was:
>>
>> em8300_i2c_init1:
>> Init the one i2c bus and get EEPROM device.
>>
>> em8300_i2c_init2:
>> Init other i2c bus and load needed modules Based on the model
>> detection (EEPROM) and setup
>> em->encoder.
>
> I think you're right if the module for the encoder chip was not loaded
> before em8300_i2c_init2. But if it was loaded before em8300_i2c_init1,
> then I think your change breaks autodetection with linux < 2.6.22.
>

Hmm... I don't get it why this change should break something. Can you
give me some hints?
Because this change only set up both i2c busses... nothing more... i
don't changed the way
the busses are used.

>
>> Do you think its worth to keep supporting older kernels? As far as I can see
>> releases are often releases to fix support with newest linux kernels. So there
>> are no new features which are worth updating.
>
> Well, that's a difficult question...
>
> There used to be at least a user of the em8300 driver who used linux 2.4
> and did not want to switch to linux 2.6. Since I don't really like the
> way the 2.6 branch is handled (with the "stable API is nonsense" moto),
> I was willing to support em8300 with linux 2.4...
>
> Now, I think this user has switched to linux 2.6, and I haven't heard
> about anyone who still uses the em8300 driver with linux 2.4. Hence, I
> should consider stopping support for old kernels (which would include
> all 2.4 kernels, and early 2.6 kernels). But where should the limit be?
>
> As for the lack of new features in recent releases of em8300,
> unfortunately you're right. The last new feature was in 0.17.0, in april
> 2008... But I still hope I'll find some time to add new features in
> future releases. And I'm not willing to impose a new kernel to anyone
> who wants to use the new feature...

What features are missing?

>
> It'd be interesting to know what kernel version people are really
> using...
>
>
>> Again I picked up an old item on my wishlist and I started working on
>> using v4l2 i2c subdevices
>> for the encoder part. This allows us to use the adv717x/bt865 driver
>> from mainline kernel.
>> As I have lot of time until next year I would like to send much time
>> with this driver.
>
> That sounds great. Do you think it will be possible to use the
> adv717x/bt865 driver from mainline kernel without changing them?

Yes this is possible... and hope to have a proof-of-concept running in
some days.

cheers
--
Christian Gmeiner, MSc

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

First release-candidate for 0.18.0 -- please test!

2009-12-07T15:40:23Z

Hi,

The 0.17.4 release of em8300 had a few bugs:
* wrong colors of the OSD with linux 2.6.31;
* kernel ooops when the em8300 module finds a video encoder chip but
can't find a driver for it.

I think I just managed to fix those 2 bugs, and think it deserves a new
release. For this release, I'd rather keep the changes minimal, in order
not to introduce new bugs.

Unfortunately, fixing the problem with the colors required some changes
in include/linux/em8300.h in a way that affects the ABI. As a result,
all applications need to be rebuilt, against the new
include/linux/em8300.h. Hence, I think it deserves to be numbered
0.18.0, despite the lack of any new feature.

Hence, here is the first release candidate for 0.18.0. As usual, you can
get it from
http://dxr3.sourceforge.net/download/em8300-0.18.0-rc1.tar.gz

Many thanks to all those who made this first release candidate possible.

All comments are welcome. Please give it a try and report.

Cheers,

Nicolas

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

Re: [PULL REQUEST] i2c changes

2009-12-07T08:46:06Z

> It'd be interesting to know what kernel version people are really
> using...
>
2.6.30 atm

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

What kernel version are you using? (Was: Re: [PULL REQUEST] i2c changes)

2009-12-07T01:53:22Z

Hi Nicolas,

Am 06.12.2009 23:27, schrieb Nicolas Boullis:
> It'd be interesting to know what kernel version people are really
> using...

2.6.32

- jan

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

em8300-headers removed from debian testing

2009-12-07T01:47:44Z

Hi there ;)

I'm building the debs for MMS (see below). As MMS is able to use DXR3 as
output device, I need em8300-headers as a build-depend.

As far as I've noticed, the headers were removed from debian testing due to
rc-bugs.

What are your plans on this? For now I've copied em8300-headers over to my
repo, for beeing able to build for squeeze, but that is only a workaround, no
solution ;)

Regards
Roman
--

Homepage:
www.mymediasystem.org
-
Forum:
forum.mymediasystem.org
-
Wiki:
wiki.mymediasystem.org
-
Bug-DB:
bugs.mymediasystem.org

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

Re: [PULL REQUEST] i2c changes

2009-12-06T14:27:47Z

Hi Christian,

On Sun, Dec 06, 2009 at 06:05:33PM +0100, Christian Gmeiner wrote:

>
> All you told is correct, but my patch does this:
>
> em8300_i2c_init1:
> Init the two i2c buses and get EEPROM device.
>
> em8300_i2c_init2:
> Based on the model detection (EEPROM) load needed modules and setup
> em->encoder.
>
> Now you need to have a look at the context where they get called.
>

(...)

>
> So there is no breaking change for auto detection. The old behavior was:
>
> em8300_i2c_init1:
> Init the one i2c bus and get EEPROM device.
>
> em8300_i2c_init2:
> Init other i2c bus and load needed modules Based on the model
> detection (EEPROM) and setup
> em->encoder.

I think you're right if the module for the encoder chip was not loaded
before em8300_i2c_init2. But if it was loaded before em8300_i2c_init1,
then I think your change breaks autodetection with linux < 2.6.22.

> Do you think its worth to keep supporting older kernels? As far as I can see
> releases are often releases to fix support with newest linux kernels. So there
> are no new features which are worth updating.

Well, that's a difficult question...

There used to be at least a user of the em8300 driver who used linux 2.4
and did not want to switch to linux 2.6. Since I don't really like the
way the 2.6 branch is handled (with the "stable API is nonsense" moto),
I was willing to support em8300 with linux 2.4...

Now, I think this user has switched to linux 2.6, and I haven't heard
about anyone who still uses the em8300 driver with linux 2.4. Hence, I
should consider stopping support for old kernels (which would include
all 2.4 kernels, and early 2.6 kernels). But where should the limit be?

As for the lack of new features in recent releases of em8300,
unfortunately you're right. The last new feature was in 0.17.0, in april
2008... But I still hope I'll find some time to add new features in
future releases. And I'm not willing to impose a new kernel to anyone
who wants to use the new feature...

It'd be interesting to know what kernel version people are really
using...

> Again I picked up an old item on my wishlist and I started working on
> using v4l2 i2c subdevices
> for the encoder part. This allows us to use the adv717x/bt865 driver
> from mainline kernel.
> As I have lot of time until next year I would like to send much time
> with this driver.

That sounds great. Do you think it will be possible to use the
adv717x/bt865 driver from mainline kernel without changing them?

Cheers,

Nicolas

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

Re: [Pull Request]

2009-12-06T09:06:34Z

Hi Nicolas,

I will send out a new pull request, when my i2c changes are in :)

greets,
--
Christian Gmeiner, MSc

2009/12/6 Nicolas Boullis <nboullis@...>:

> Hi Christian,
>
> On Fri, Oct 16, 2009 at 01:03:41PM +0200, Christian Gmeiner wrote:
>> Hi Nicolas,
>>
>> at the moment I try to implement stillpicture support into the
>> vdr-plugin-dxr3, but I run into some problems with playmodes.
>> And after a quick look at the driver I found out why. Many playmodes
>> are not supported and the ioctl does always return 0.
>> Hope this patch get in... and I am quite sure I will find other places
>> where I will write a patch for.
>>
>> http://hg.assembla.com/em8300-cgmeiner
>
> Sorry for the very late answer. Is that patch still available somewhere?
>
>
> Cheers,
>
> Nicolas
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Dxr3-devel mailing list
> Dxr3-devel@...
> https://lists.sourceforge.net/lists/listinfo/dxr3-devel
>

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

Re: [PULL REQUEST] i2c changes

2009-12-06T09:05:33Z

Hi Nicolas,

2009/12/6 Nicolas Boullis <nboullis@...>:

> Hi Christian,
>
> On Wed, Dec 02, 2009 at 10:37:49AM +0100, Christian Gmeiner wrote:
>> Hi Nicolas,
>>
>> is it possible that you merge my tree at
>> http://hg.assembla.com/em8300-cgmeiner for the following changes?
>>
>> - fix some stuff reported by checkpatch.pl
>> - restruct code to make use of arrays
>> - introduce i2c_algo_bit_data array
>> - create nicer names for i2c adapters
>> - fix Indent style
>> - move setup of bus 1 to em8300_i2c_init1
>> - make use of array in em8300_i2c_exit
>> - create a i2c_adapter array and make use of it
>> - introduce em8300_i2c_adap_template
>> - move defines and datastructes used for driver compilation into
>>
>> If you have any problems with my patches, let me know it.
>
> At first sight, it looks fine, except the "move setup of bus 1 to
> em8300_i2c_init1" part.
>
> As far as I remember, I did split the setup of both busses for the
> autoconfiguration: the kind of model has to be known (which requires
> reading the EEPROM, on bus 2) before the encoder chip is initialized.
> With old-style I2C, the encoder chip might be detected (and intialized)
> as soon as bus 1 is set up. That's why I had to move the setup of bus 1
> after the identification of the model.

All you told is correct, but my patch does this:

em8300_i2c_init1:
Init the two i2c buses and get EEPROM device.

em8300_i2c_init2:
Based on the model detection (EEPROM) load needed modules and setup
em->encoder.

Now you need to have a look at the context where they get called.

static int init_em8300(struct em8300_s *em)
{
int identified_model;

write_register(0x30000, read_register(0x30000));

write_register(0x1f50, 0x123);

if (read_register(0x1f50) == 0x123)
em->chip_revision = 2;
else
em->chip_revision = 1;

em8300_i2c_init1(em);
em8300_eeprom_checksum_init(em);

identified_model = identify_model(em);

...
...
...

pr_info("em8300-%d: Chip revision: %d\n", em->card_nr, em->chip_revision);
pr_debug("em8300-%d: use_bt865: %d\n", em->card_nr,
em->config.model.use_bt865);

em8300_i2c_init2(em);

So there is no breaking change for auto detection. The old behavior was:

em8300_i2c_init1:
Init the one i2c bus and get EEPROM device.

em8300_i2c_init2:
Init other i2c bus and load needed modules Based on the model
detection (EEPROM) and setup
em->encoder.

>
> Note that with linux >= 2.6.22, bus 1 uses new-style I2C. So your patch
> may only break things for older linux kernels.

I think it will not break compatibility with linux < 2.6.22.

>
> The best way would probably be to rework the way the initialization of
> the encoder chip is handled, but that looks like some complex work (as
> long as I don't want to break compatibity with linux < 2.6.22).
>

Do you think its worth to keep supporting older kernels? As far as I can see
releases are often releases to fix support with newest linux kernels. So there
are no new features which are worth updating.

Again I picked up an old item on my wishlist and I started working on
using v4l2 i2c subdevices
for the encoder part. This allows us to use the adv717x/bt865 driver
from mainline kernel.
As I have lot of time until next year I would like to send much time
with this driver.

greets,
--
Christian Gmeiner, MSc

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

Re: [Pull Request]

2009-12-05T16:30:21Z

Hi Christian,

On Fri, Oct 16, 2009 at 01:03:41PM +0200, Christian Gmeiner wrote:

> Hi Nicolas,
>
> at the moment I try to implement stillpicture support into the
> vdr-plugin-dxr3, but I run into some problems with playmodes.
> And after a quick look at the driver I found out why. Many playmodes
> are not supported and the ioctl does always return 0.
> Hope this patch get in... and I am quite sure I will find other places
> where I will write a patch for.
>
> http://hg.assembla.com/em8300-cgmeiner

Sorry for the very late answer. Is that patch still available somewhere?

Cheers,

Nicolas

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

Re: [PULL REQUEST] i2c changes

2009-12-05T16:28:21Z

Hi Christian,

On Wed, Dec 02, 2009 at 10:37:49AM +0100, Christian Gmeiner wrote:

> Hi Nicolas,
>
> is it possible that you merge my tree at
> http://hg.assembla.com/em8300-cgmeiner for the following changes?
>
> - fix some stuff reported by checkpatch.pl
> - restruct code to make use of arrays
> - introduce i2c_algo_bit_data array
> - create nicer names for i2c adapters
> - fix Indent style
> - move setup of bus 1 to em8300_i2c_init1
> - make use of array in em8300_i2c_exit
> - create a i2c_adapter array and make use of it
> - introduce em8300_i2c_adap_template
> - move defines and datastructes used for driver compilation into
>
> If you have any problems with my patches, let me know it.

At first sight, it looks fine, except the "move setup of bus 1 to
em8300_i2c_init1" part.

As far as I remember, I did split the setup of both busses for the
autoconfiguration: the kind of model has to be known (which requires
reading the EEPROM, on bus 2) before the encoder chip is initialized.
With old-style I2C, the encoder chip might be detected (and intialized)
as soon as bus 1 is set up. That's why I had to move the setup of bus 1
after the identification of the model.

Note that with linux >= 2.6.22, bus 1 uses new-style I2C. So your patch
may only break things for older linux kernels.

The best way would probably be to rework the way the initialization of
the encoder chip is handled, but that looks like some complex work (as
long as I don't want to break compatibity with linux < 2.6.22).

Cheers,

Nicolas

PS: no need to CC me, I read the list.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

Re: em8300 with 2.6.32?

2009-12-04T17:16:01Z

Hello all,

It was very stupid - I checked my compilation process again and found
that it didn't copy patched em8300.h into /usr/include/linux/em8300.h .
OSD is fixed - Nicolas and Christian, thanks!!

Best,

Yarema

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

Re: em8300 with 2.6.32?

2009-12-04T09:00:59Z

Hi Nicolas,

Am 03.12.2009 18:02, schrieb Nicolas Boullis:
> I just saw that linux 2.6.32 was released. Has anyone had the
> opportunity to test em8300 with the new linux kernel, or a recent
> release candidate?

Compiles and loads fine on 2.6.32:

Sigma Designs EM8300 0000:02:05.0: PCI INT A -> GSI 17 (level, low) ->
IRQ 17
em8300-0: EM8300 8300 (rev 2)
bus: 2, devfn: 40, irq: 17,
memory: 0xf4100000.
em8300-0: mapped-memory at 0xd1980000
em8300-0: using MTRR
IRQ 17/em8300: IRQF_DISABLED is not guaranteed on shared IRQs
i2c i2c-1: sendbytes: NAK bailout.
em8300-0: unable to identify model...
em8300-0: Chip revision: 2
i2c i2c-0: sendbytes: NAK bailout.
adv717x.o: ADV7175A rev. 0 chip probed
unable to register OSS PCM device 0:0
em8300-0: Microcode version 0x29 loaded
em8300-0: Analog audio enabled
em8300-0: Digital PCM audio enabled

[jan@server modules]$ ll /dev/dsp
crw-rw---- 1 root audio 14, 3 4. Dez 15:00 /dev/dsp
[jan@server modules]$ ll /dev/em8300*
crw-rw---- 1 root video 121, 0 4. Dez 15:00 /dev/em8300-0
crw-rw---- 1 root video 121, 2 4. Dez 15:00 /dev/em8300_ma-0
crw-rw---- 1 root video 121, 1 4. Dez 15:00 /dev/em8300_mv-0
crw-rw---- 1 root video 121, 3 4. Dez 15:00 /dev/em8300_sp-0

options adv717x pixelport_16bit=0
options em8300 alsa_id=EM8300-1

Sound works though.

I used Christians repo (http://hg.assembla.com/em8300-cgmeiner) and
Nicolas patch. OSD colours are fixed, nice!

cheers,

- jan

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

Re: em8300 with 2.6.32?

2009-12-04T06:00:49Z

The OSD was applied - forgot the mention it

2009/12/4 Nicolas Boullis <nboullis@...>:

> Hi Christian,
>
> On Fri, Dec 04, 2009 at 09:31:56AM +0100, Christian Gmeiner wrote:
>> Works with 2.6.32.. no patches etc needed.
>
> That's excellent news!
> Not even the patch for OSD colors, or did you apply it?
>
>
> Thanks for your report,
>
> Nicolas
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Dxr3-devel mailing list
> Dxr3-devel@...
> https://lists.sourceforge.net/lists/listinfo/dxr3-devel
>

--
Christian Gmeiner, MSc

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

Re: em8300 with 2.6.32? - tested

2009-12-04T04:48:55Z

I compiled 2.6.32 kernel and tested em8300 drivers. Compilation was
smooth, I applied a last patch for em8300 and compiled against new
kernel. Rebooted. Here is a log after modprobe em8300:

Sigma Designs EM8300 0000:01:06.0: PCI INT A -> Link[APC3] -> GSI 18
(level, low) -> IRQ 18
Sigma Designs EM8300 0000:01:06.0: setting latency timer to 64
em8300-0: EM8300 8300 (rev 1)
bus: 1, devfn: 48, irq: 18,
memory: 0xefc00000.
em8300-0: mapped-memory at 0xf8c00000
em8300-0: using MTRR
IRQ 18/em8300: IRQF_DISABLED is not guaranteed on shared IRQs
em8300-0: detected card: Hollywood+ type 1.
em8300-0: Chip revision: 2
i2c i2c-4: sendbytes: NAK bailout.
adv717x.o: ADV7175A rev. 0 chip probed
unable to register OSS PCM device 1:0

I didn't compile dxr3 driver, so can say nothing about OSD issue. Maybe
later when 2.6.32 kernel appears in the repository.

Regards,

Yarema

Nicolas Boullis написав(ла):

> Hi,
>
> I just saw that linux 2.6.32 was released. Has anyone had the
> opportunity to test em8300 with the new linux kernel, or a recent
> release candidate?
>
>
> Regards,
>
> Nicolas
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Dxr3-devel mailing list
> Dxr3-devel@...
> https://lists.sourceforge.net/lists/listinfo/dxr3-devel
>

Re: em8300 with 2.6.32?

2009-12-04T04:43:24Z

Hi Christian,

On Fri, Dec 04, 2009 at 09:31:56AM +0100, Christian Gmeiner wrote:
> Works with 2.6.32.. no patches etc needed.

That's excellent news!
Not even the patch for OSD colors, or did you apply it?

Thanks for your report,

Nicolas

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

Re: em8300 with 2.6.32?

2009-12-04T00:31:56Z

Works with 2.6.32.. no patches etc needed.

2009/12/3 YUP <yupadmin@...>:

> Hi,
>
> I think that in a few days 2.6.32 stable will be in the archlinux core
> repository and I can test it.
> As for a present moment I can test 2.6.32 rc8, but it takes some time to
> compile. Probably I'll start it now.
>
> Yarema
>
>
>
> Nicolas Boullis написав(ла):
>> Hi,
>>
>> I just saw that linux 2.6.32 was released. Has anyone had the
>> opportunity to test em8300 with the new linux kernel, or a recent
>> release candidate?
>>
>>
>> Regards,
>>
>> Nicolas
>>
>> ------------------------------------------------------------------------------
>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>> a free event focused on virtualization and cloud computing.
>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>> http://p.sf.net/sfu/redhat-sfdev2dev
>> _______________________________________________
>> Dxr3-devel mailing list
>> Dxr3-devel@...
>> https://lists.sourceforge.net/lists/listinfo/dxr3-devel
>>
>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Dxr3-devel mailing list
> Dxr3-devel@...
> https://lists.sourceforge.net/lists/listinfo/dxr3-devel
>

Re: em8300 with 2.6.32?

2009-12-03T11:19:39Z

Hi,

I think that in a few days 2.6.32 stable will be in the archlinux core
repository and I can test it.
As for a present moment I can test 2.6.32 rc8, but it takes some time to
compile. Probably I'll start it now.

Yarema

Nicolas Boullis написав(ла):

em8300 with 2.6.32?

2009-12-03T09:02:46Z

Hi,

I just saw that linux 2.6.32 was released. Has anyone had the
opportunity to test em8300 with the new linux kernel, or a recent
release candidate?

Regards,

Nicolas

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

Re: [PATCH] wrong colors for OSD with linux 2.6.31

2009-12-02T12:44:19Z

Hi,

On Wed, Dec 02, 2009 at 07:27:39PM +0100, Christian Gmeiner wrote:
> After I have done this and compiled driver and plugin it works now :)

That's good news. :-) I'll push this change as soon as I am back home.

Regards,

Nicolas

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

Re: [PATCH] wrong colors for OSD with linux 2.6.31

2009-12-02T11:00:57Z

Dunno, in my case it doesn't work. I attached PKGBUILDs for em8300, em8300-utils and vdr-plugin-dxr3, can you point out what is wrong?

Regards,

Yarema

2009/12/2 Christian Gmeiner <christian.gmeiner@...>

Nicolas,

it works now... I was sooo stupid and forgot to do
modules # cp ../include/linux/em8300.h /usr/include/linux/
After I have done this and compiled driver and plugin it works now :)

Great...

--

Christian Gmeiner, MSc

em8300-hg.tar.gz (2K) Download Attachment
em8300-utils-hg.tar.gz (1K) Download Attachment
vdr-plugin-dxr3-git.tar.gz (1K) Download Attachment

Re: [PATCH] wrong colors for OSD with linux 2.6.31

2009-12-02T10:27:39Z

Nicolas,

it works now... I was sooo stupid and forgot to do
modules # cp ../include/linux/em8300.h /usr/include/linux/
After I have done this and compiled driver and plugin it works now :)

Great...

--
Christian Gmeiner, MSc

2009/12/2 YUP <yupadmin@...>:

> Same for me. I compiled em8300 modules with the last patch and also
> recompiled dxr3 plugin for vdr.
>
> Regards,
>
> Yarema
>
> Christian Gmeiner написав(ла):
>> Okay... for me this patch does _NOT_ solve the color problems with the OSD.
>>
>> greets,
>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Dxr3-devel mailing list
> Dxr3-devel@...
> https://lists.sourceforge.net/lists/listinfo/dxr3-devel
>

Re: [PATCH] wrong colors for OSD with linux 2.6.31

2009-12-02T06:09:27Z

Same for me. I compiled em8300 modules with the last patch and also
recompiled dxr3 plugin for vdr.

Regards,

Yarema

Christian Gmeiner написав(ла):
> Okay... for me this patch does _NOT_ solve the color problems with the OSD.
>
> greets,

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

Re: [PATCH] wrong colors for OSD with linux 2.6.31

2009-12-02T05:50:27Z

Okay... for me this patch does _NOT_ solve the color problems with the OSD.

greets,
--
Christian Gmeiner, MSc

2009/12/2 Christian Gmeiner <christian.gmeiner@...>:

> Here is an updated patch, which compiles - no runtime test done yet.
>
> At the moment i am switching to the most recent stable kernel and
> integrate needed changes
> into vdr-dxr3-plugin.
>
> greets
> --
> Christian Gmeiner, MSc
>
> 2009/12/2 YUP <yupadmin@...>:
>> Hi Nicolas,
>>
>> I tried to apply your patch to the last em8300-1.7.4 and to em8300 from
>> em8300-cgmeiner hg repository (http://hg.assembla.com/em8300-cgmeiner).
>> In both cases I cannot compile this staff with the same errors:
>>
>> [vdr@archvdr em8300-cgmeiner]$ patch -p1 < ../em8300_ioctl.patch
>> patching file include/linux/em8300.h
>>
>> [vdr@archvdr em8300-cgmeiner/modules]$ LANG=C make
>> [ ! -x ./update_em8300_version.sh ] || ./update_em8300_version.sh
>> em8300_version.h
>> make -C /lib/modules/2.6.31-ARCH/build
>> SUBDIRS=/home/vdr/install/em8300-hg/em8300-cgmeiner/modules modules
>> make[1]: Entering directory `/usr/src/linux-2.6.31-ARCH'
>> CC [M] /home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.o
>> /home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c: In
>> function 'em8300_spu_ioctl':
>> /home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c:141:
>> error: implicit declaration of function '_IOW'
>> /home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c:141:
>> error: expected expression before 'int'
>> /home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c:141:
>> error: case label does not reduce to an integer constant
>> /home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c:148:
>> error: expected expression before 'unsigned'
>> /home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c:148:
>> error: case label does not reduce to an integer constant
>> /home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c:153:
>> error: expected expression before 'em8300_button_t'
>> /home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c:153:
>> error: case label does not reduce to an integer constant
>> make[2]: ***
>> [/home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.o] Error 1
>> make[1]: ***
>> [_module_/home/vdr/install/em8300-hg/em8300-cgmeiner/modules] Error 2
>> make[1]: Leaving directory `/usr/src/linux-2.6.31-ARCH'
>> make: *** [build] Error 2
>>
>> Regards,
>>
>> Yarema
>>
>>
>> Nicolas Boullis написав(ла):
>>> Hi,
>>>
>>> After quite some work, I think I found why OSD is displayed with wrong
>>> colors with linux 2.6.31.
>>>
>>> The good news is that I wrote a patch that *should* solve the problem.
>>> (I am curently away from home so I can't check if the problem is really
>>> solved.)
>>>
>>> The bad news is that I had to change the numeric value of the
>>> EM8300_IOCTL_SPU_SETPALETTE ioctl (and in fact I changed a few other
>>> ones as well). This means that any application using this ioctl must be
>>> rebuilt against the new em8300.h to work with the new modules.
>>>
>>> Applicatin writers who want to build applications that support both old
>>> and new modules may replace
>>> ret = ioctl(fd, EM8300_IOCTL_SPU_SETPALETTE, palette);
>>> with
>>> ret = ioctl(fd, EM8300_IOCTL_SPU_SETPALETTE, palette);
>>> if ((ret < 0) && (errno = EINVAL))
>>> /* built against the new em8300.h but old module */
>>> ret = ioctl(fd, 2, palette);
>>>
>>> If you use inux 2.6.31 and experience wrong colors with the OSD, please
>>> give this patch a try and report.
>>> *PLEASE DON'T FORGET TO REBUILD YOUR APPLICATION.*
>>>
>>> Cheers,
>>>
>>> Nicolas
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>
>> ------------------------------------------------------------------------------
>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>> a free event focused on virtualization and cloud computing.
>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>> http://p.sf.net/sfu/redhat-sfdev2dev
>> _______________________________________________
>> Dxr3-devel mailing list
>> Dxr3-devel@...
>> https://lists.sourceforge.net/lists/listinfo/dxr3-devel
>>
>

Re: [PATCH] wrong colors for OSD with linux 2.6.31

2009-12-02T04:51:48Z

Here is an updated patch, which compiles - no runtime test done yet.

At the moment i am switching to the most recent stable kernel and
integrate needed changes
into vdr-dxr3-plugin.

greets
--
Christian Gmeiner, MSc

2009/12/2 YUP <yupadmin@...>:

> Hi Nicolas,
>
> I tried to apply your patch to the last em8300-1.7.4 and to em8300 from
> em8300-cgmeiner hg repository (http://hg.assembla.com/em8300-cgmeiner).
> In both cases I cannot compile this staff with the same errors:
>
> [vdr@archvdr em8300-cgmeiner]$ patch -p1 < ../em8300_ioctl.patch
> patching file include/linux/em8300.h
>
> [vdr@archvdr em8300-cgmeiner/modules]$ LANG=C make
> [ ! -x ./update_em8300_version.sh ] || ./update_em8300_version.sh
> em8300_version.h
> make -C /lib/modules/2.6.31-ARCH/build
> SUBDIRS=/home/vdr/install/em8300-hg/em8300-cgmeiner/modules modules
> make[1]: Entering directory `/usr/src/linux-2.6.31-ARCH'
> CC [M] /home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.o
> /home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c: In
> function 'em8300_spu_ioctl':
> /home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c:141:
> error: implicit declaration of function '_IOW'
> /home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c:141:
> error: expected expression before 'int'
> /home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c:141:
> error: case label does not reduce to an integer constant
> /home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c:148:
> error: expected expression before 'unsigned'
> /home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c:148:
> error: case label does not reduce to an integer constant
> /home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c:153:
> error: expected expression before 'em8300_button_t'
> /home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c:153:
> error: case label does not reduce to an integer constant
> make[2]: ***
> [/home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.o] Error 1
> make[1]: ***
> [_module_/home/vdr/install/em8300-hg/em8300-cgmeiner/modules] Error 2
> make[1]: Leaving directory `/usr/src/linux-2.6.31-ARCH'
> make: *** [build] Error 2
>
> Regards,
>
> Yarema
>
>
> Nicolas Boullis написав(ла):
>> Hi,
>>
>> After quite some work, I think I found why OSD is displayed with wrong
>> colors with linux 2.6.31.
>>
>> The good news is that I wrote a patch that *should* solve the problem.
>> (I am curently away from home so I can't check if the problem is really
>> solved.)
>>
>> The bad news is that I had to change the numeric value of the
>> EM8300_IOCTL_SPU_SETPALETTE ioctl (and in fact I changed a few other
>> ones as well). This means that any application using this ioctl must be
>> rebuilt against the new em8300.h to work with the new modules.
>>
>> Applicatin writers who want to build applications that support both old
>> and new modules may replace
>> ret = ioctl(fd, EM8300_IOCTL_SPU_SETPALETTE, palette);
>> with
>> ret = ioctl(fd, EM8300_IOCTL_SPU_SETPALETTE, palette);
>> if ((ret < 0) && (errno = EINVAL))
>> /* built against the new em8300.h but old module */
>> ret = ioctl(fd, 2, palette);
>>
>> If you use inux 2.6.31 and experience wrong colors with the OSD, please
>> give this patch a try and report.
>> *PLEASE DON'T FORGET TO REBUILD YOUR APPLICATION.*
>>
>> Cheers,
>>
>> Nicolas
>>
>>
>> ------------------------------------------------------------------------
>>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Dxr3-devel mailing list
> Dxr3-devel@...
> https://lists.sourceforge.net/lists/listinfo/dxr3-devel
>

spu_v2.patch (1K) Download Attachment

Re: [PATCH] wrong colors for OSD with linux 2.6.31

2009-12-02T04:35:34Z

Hi Nicolas,

I tried to apply your patch to the last em8300-1.7.4 and to em8300 from
em8300-cgmeiner hg repository (http://hg.assembla.com/em8300-cgmeiner).
In both cases I cannot compile this staff with the same errors:

[vdr@archvdr em8300-cgmeiner]$ patch -p1 < ../em8300_ioctl.patch
patching file include/linux/em8300.h

[vdr@archvdr em8300-cgmeiner/modules]$ LANG=C make
[ ! -x ./update_em8300_version.sh ] || ./update_em8300_version.sh
em8300_version.h
make -C /lib/modules/2.6.31-ARCH/build
SUBDIRS=/home/vdr/install/em8300-hg/em8300-cgmeiner/modules modules
make[1]: Entering directory `/usr/src/linux-2.6.31-ARCH'
CC [M] /home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.o
/home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c: In
function 'em8300_spu_ioctl':
/home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c:141:
error: implicit declaration of function '_IOW'
/home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c:141:
error: expected expression before 'int'
/home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c:141:
error: case label does not reduce to an integer constant
/home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c:148:
error: expected expression before 'unsigned'
/home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c:148:
error: case label does not reduce to an integer constant
/home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c:153:
error: expected expression before 'em8300_button_t'
/home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.c:153:
error: case label does not reduce to an integer constant
make[2]: ***
[/home/vdr/install/em8300-hg/em8300-cgmeiner/modules/em8300_spu.o] Error 1
make[1]: ***
[_module_/home/vdr/install/em8300-hg/em8300-cgmeiner/modules] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.31-ARCH'
make: *** [build] Error 2

Regards,

Yarema

Nicolas Boullis написав(ла):

> Hi,
>
> After quite some work, I think I found why OSD is displayed with wrong
> colors with linux 2.6.31.
>
> The good news is that I wrote a patch that *should* solve the problem.
> (I am curently away from home so I can't check if the problem is really
> solved.)
>
> The bad news is that I had to change the numeric value of the
> EM8300_IOCTL_SPU_SETPALETTE ioctl (and in fact I changed a few other
> ones as well). This means that any application using this ioctl must be
> rebuilt against the new em8300.h to work with the new modules.
>
> Applicatin writers who want to build applications that support both old
> and new modules may replace
> ret = ioctl(fd, EM8300_IOCTL_SPU_SETPALETTE, palette);
> with
> ret = ioctl(fd, EM8300_IOCTL_SPU_SETPALETTE, palette);
> if ((ret < 0) && (errno = EINVAL))
> /* built against the new em8300.h but old module */
> ret = ioctl(fd, 2, palette);
>
> If you use inux 2.6.31 and experience wrong colors with the OSD, please
> give this patch a try and report.
> *PLEASE DON'T FORGET TO REBUILD YOUR APPLICATION.*
>
> Cheers,
>
> Nicolas
>
>
> ------------------------------------------------------------------------
>

[PULL REQUEST] i2c changes

2009-12-02T01:37:49Z

Hi Nicolas,

is it possible that you merge my tree at
http://hg.assembla.com/em8300-cgmeiner for the following changes?

- fix some stuff reported by checkpatch.pl
- restruct code to make use of arrays
- introduce i2c_algo_bit_data array
- create nicer names for i2c adapters
- fix Indent style
- move setup of bus 1 to em8300_i2c_init1
- make use of array in em8300_i2c_exit
- create a i2c_adapter array and make use of it
- introduce em8300_i2c_adap_template
- move defines and datastructes used for driver compilation into

If you have any problems with my patches, let me know it.

thanks
--
Christian Gmeiner, MSc

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

[PATCH] wrong colors for OSD with linux 2.6.31

2009-12-01T14:59:12Z

Hi,

After quite some work, I think I found why OSD is displayed with wrong
colors with linux 2.6.31.

The good news is that I wrote a patch that *should* solve the problem.
(I am curently away from home so I can't check if the problem is really
solved.)

The bad news is that I had to change the numeric value of the
EM8300_IOCTL_SPU_SETPALETTE ioctl (and in fact I changed a few other
ones as well). This means that any application using this ioctl must be
rebuilt against the new em8300.h to work with the new modules.

Applicatin writers who want to build applications that support both old
and new modules may replace
ret = ioctl(fd, EM8300_IOCTL_SPU_SETPALETTE, palette);
with
ret = ioctl(fd, EM8300_IOCTL_SPU_SETPALETTE, palette);
if ((ret < 0) && (errno = EINVAL))
/* built against the new em8300.h but old module */
ret = ioctl(fd, 2, palette);

If you use inux 2.6.31 and experience wrong colors with the OSD, please
give this patch a try and report.
*PLEASE DON'T FORGET TO REBUILD YOUR APPLICATION.*

Cheers,

Nicolas

# HG changeset patch # User Nicolas Boullis <nboullis@...> # Date 1259676141 -3600 # Node ID a3dd4e08e9bab3205bca0ef443f3ae7e49463e6f # Parent a6d163d061475ba115c1b69021af4a3257d20868 Change the numeric value of a few ioctls. The EM8300_IOCTL_SPU_SETPALETTE ioctl used to have a value of 2. But 2 is also FIGETBSZ. Since linux 2.6.31 (commit 19ba0559f9ce104171ab16706893ce01f03ef116), the FIGETBSZ ioctl is handled in do_vfs_ioctl (it used to be handled in file_ioctl). The result is that EM8300_IOCTL_SPU_SETPALETTE ioctls are catched as FIGETBSZ in do_vfs_ioctl and never reach the em8300_io_ioctl, em8300_spu_ioctl and em8300_spu_setpalette functions. In a word: it does not work. Hence, change the numeric value of the EM8300_IOCTL_SPU_SETPALETTE ioctl, and also the EM8300_IOCTL_VIDEO_SETPTS, EM8300_IOCTL_SPU_SETPTS and EM8300_IOCTL_SPU_BUTTON ioctls. Note: Since the numeric values of the ioctls have changed, the ABI has changed and any application using these ioctls needs rebuilding. diff --git a/include/linux/em8300.h b/include/linux/em8300.h --- a/include/linux/em8300.h +++ b/include/linux/em8300.h @@ -114,13 +114,13 @@ typedef struct { #define EM8300_OVERLAY_SIGNAL_WITH_VGA 2 #define EM8300_OVERLAY_VGA_ONLY 3 -#define EM8300_IOCTL_VIDEO_SETPTS 1 +#define EM8300_IOCTL_VIDEO_SETPTS _IOW('C',1,int) #define EM8300_IOCTL_VIDEO_GETSCR _IOR('C',2,unsigned) #define EM8300_IOCTL_VIDEO_SETSCR _IOW('C',2,unsigned) -#define EM8300_IOCTL_SPU_SETPTS 1 -#define EM8300_IOCTL_SPU_SETPALETTE 2 -#define EM8300_IOCTL_SPU_BUTTON 3 +#define EM8300_IOCTL_SPU_SETPTS _IOW('C',1,int) +#define EM8300_IOCTL_SPU_SETPALETTE _IOW('C',2,unsigned[16]) +#define EM8300_IOCTL_SPU_BUTTON _IOW('C',3,em8300_button_t) #define EM8300_ASPECTRATIO_4_3 0 #define EM8300_ASPECTRATIO_16_9 1

Re: vdr, em8300 0.17.4 and OSD

2009-11-24T04:13:57Z

Hi,

okay... the kernel is too new for 0.17.3. It looks like I have some
hours free to work on it today. Maybe I can
find the bug.

lg
--
Christian Gmeiner, MSc

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

Re: vdr, em8300 0.17.4 and OSD

2009-11-24T04:09:01Z

I forgot to say, then even applying the proposed em8300.patch I still
cannot compile modules, compilation hangs up with the following:

[vdr@archvdr modules]$ LANG=C make
[ ! -x ./update_em8300_version.sh ] || ./update_em8300_version.sh
em8300_version.h
make -C /lib/modules/2.6.31-ARCH/build
SUBDIRS=/home/vdr/install/em8300/em8300-0.17.3/modules modules
make[1]: Entering directory `/usr/src/linux-2.6.31-ARCH'
CC [M] /home/vdr/install/em8300/em8300-0.17.3/modules/adv717x.o
/home/vdr/install/em8300/em8300-0.17.3/modules/adv717x.c:236: error:
unknown field 'detach_client' specified in initializer
/home/vdr/install/em8300/em8300-0.17.3/modules/adv717x.c:236: warning:
initialization from incompatible pointer type
/home/vdr/install/em8300/em8300-0.17.3/modules/adv717x.c: In function
'adv717x_detect':
/home/vdr/install/em8300/em8300-0.17.3/modules/adv717x.c:726: error:
implicit declaration of function 'i2c_attach_client'
/home/vdr/install/em8300/em8300-0.17.3/modules/adv717x.c: In function
'adv717x_detach_client':
/home/vdr/install/em8300/em8300-0.17.3/modules/adv717x.c:756: error:
implicit declaration of function 'i2c_detach_client'
make[2]: *** [/home/vdr/install/em8300/em8300-0.17.3/modules/adv717x.o]
Error 1
make[1]: *** [_module_/home/vdr/install/em8300/em8300-0.17.3/modules]
Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.31-ARCH'
make: *** [build] Error 2

Regards,

Yarema

> The problem is know and I suggest you to switch back to em8300-0.17.3
> and the OSD should be fixed.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

Re: vdr, em8300 0.17.4 and OSD

2009-11-23T10:02:31Z

Right, problem is known, I have read the all thread about it. I even
tried to compile 0.17.3, but compilation stops with

~/install/em8300/em8300-0.17.3/modules/Kbuild:67: /Rules.make: No such
file or directory

As far I understand, there is some disagreement with kernel (2.6.31) and
lately it was fixed in 0.17.4.

Yarema

Christian Gmeiner написав(ла):
> The problem is know and I suggest you to switch back to em8300-0.17.3
> and the OSD should be fixed.
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

Re: vdr, em8300 0.17.4 and OSD

2009-11-23T09:33:15Z

The problem is know and I suggest you to switch back to em8300-0.17.3
and the OSD should be fixed.

2009/11/23 YUP <yupadmin@...>:

> Hi,
>
> I have a problem with the current em8300 driver. Actually I'm using
> archlinux with the stock 2.6.31 kernel, em8300-0.17.4 drivers and vdr
> 1.7.0 with dxr3 plugin. I have read that the previous version, 0.17.3,
> had the same bug with OSD.
> I uploaded few of my screenshots: http://omploader.org/vMnU5aQ ,
> http://omploader.org/vMnU5bA , http://omploader.org/vMnU5bQ . I can also
> provide any additional information, logs etc. Just please let me know
> what you need.
>
> Regards,
>
> Yarema
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Dxr3-devel mailing list
> Dxr3-devel@...
> https://lists.sourceforge.net/lists/listinfo/dxr3-devel
>

--
Christian Gmeiner, MSc

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

vdr, em8300 0.17.4 and OSD

2009-11-23T07:37:44Z

Hi,

I have a problem with the current em8300 driver. Actually I'm using
archlinux with the stock 2.6.31 kernel, em8300-0.17.4 drivers and vdr
1.7.0 with dxr3 plugin. I have read that the previous version, 0.17.3,
had the same bug with OSD.
I uploaded few of my screenshots: http://omploader.org/vMnU5aQ ,
http://omploader.org/vMnU5bA , http://omploader.org/vMnU5bQ . I can also
provide any additional information, logs etc. Just please let me know
what you need.

Regards,

Yarema

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

[Pull Request]

2009-10-16T04:03:41Z

Hi Nicolas,

at the moment I try to implement stillpicture support into the
vdr-plugin-dxr3, but I run into some problems with playmodes.
And after a quick look at the driver I found out why. Many playmodes
are not supported and the ioctl does always return 0.
Hope this patch get in... and I am quite sure I will find other places
where I will write a patch for.

http://hg.assembla.com/em8300-cgmeiner

thanks
--
Christian Gmeiner, MSc

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel