Adding ioctl and module param for zoom ?!

[Roman Müllenschläder-2]

Hi List ;)

As of newer dxr3-module versions support setting zoom factor via sysfs (for to
avoid losses due to overscan), it would be nice to even set zoom without
sysfs and to be able to set zoom dynamically ...

Attached you'll find 2 patches for 0.16.3-rc4:

zoom-module-param:
This one adds module parameter 'scr_zoom' to set zoom at loadtime

zoom-ioctl:
This one adds possibility to set/get zoom via ioctl

Purpose for that is the following:
As lots of people are using dxr3 cards together with MMS (see below), it only
was possible to set a "zoom level" via hardcoded changes to driver
--------
/em8300/modules/em8300_dicomm.c

struct dicom_tvmode tvmodematrix[EM8300_VIDEOMODE_LAST + 1] = {
        {576, 720, 46, 130},     // PAL 4:3
        {480, 720, 46, 138},     // PAL60 4:3
        {440, 640, 60, 170},     // NTSC 4:3
//      {480, 720, 31, 138},     // NTSC 4:3

or for PAL:
{540, 660, 64, 150}, // PAL 4:3
--------

Newer driver versions support setting a zoom-factor via sysfs:
echo "90%" > "/sys/module/em8300/drivers/pci:Sigma Designs
EM8300/0000:02:00.0/zoom"

With the patches above one is able to set a zoom-factor even without sysfs or
changes to source (via module-param) or from within applications like MMS
(via config-option and ioctl) ;)

It would be really nice if these changes could go upstream cause it makes
dxr3-modules more flexible. We (the people behind MMS) had a lot of requests
concerning overscan problems with dxr3. Setting a module-param sets
zoom-factor application-wide (MMS, VDR, etc.). But with the possibility of
ioctl-calls, each app is able to set it's own factor ;)

I'm not the author of the patches but I'm in contact with original author ...

Thx
Roman

--

Homepage:
www.mymediasystem.org

Forum:
forum.mymediasystem.org

Wiki:
wiki.mymediasystem.org



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

[Nicolas Boullis]

Hi Roman (and others),

On Mon, Aug 20, 2007 at 10:36:26AM +0200, Roman Müllenschläder wrote:

> Hi List ;)
>
> As of newer dxr3-module versions support setting zoom factor via sysfs (for to
> avoid losses due to overscan), it would be nice to even set zoom without
> sysfs and to be able to set zoom dynamically ...
>
> Attached you'll find 2 patches for 0.16.3-rc4:
>
> zoom-module-param:
> This one adds module parameter 'scr_zoom' to set zoom at loadtime
>
> zoom-ioctl:
> This one adds possibility to set/get zoom via ioctl
>

(...)
>
> Newer driver versions support setting a zoom-factor via sysfs:
> echo "90%" > "/sys/module/em8300/drivers/pci:Sigma Designs
> EM8300/0000:02:00.0/zoom"

I'd suggest
  echo 90 > /sys/class/em8300/em8300-0/device/zoom
as it is more straightforward (no need to know the PCI address of the
device).


> With the patches above one is able to set a zoom-factor even without sysfs or
> changes to source (via module-param) or from within applications like MMS
> (via config-option and ioctl) ;)
>
> It would be really nice if these changes could go upstream cause it makes
> dxr3-modules more flexible. We (the people behind MMS) had a lot of requests
> concerning overscan problems with dxr3. Setting a module-param sets
> zoom-factor application-wide (MMS, VDR, etc.). But with the possibility of
> ioctl-calls, each app is able to set it's own factor ;)

As for the module parameter, this sounds like a good idea. Thanks.
But I'm not really willing to add a new em8300-specific ioctl. The
reason is that I'm willing to switch to a standard API in order to get
included into linux. Adding a new ioctl certainly does not help this
goal, but I'm all for implementing this through ioctl using a standard
API if this is possible.

By the way, it looks like only MMS users complain about overscan. As far
as I know, no xine or vdr user complained about such a problem. Any idea
why?


> I'm not the author of the patches but I'm in contact with original author ...

I's meaningless, but I'd suggest tu use the unified diff format (most if
not all free software developer I know prefer that format), and a single
(possibly gzipped) patch (generated with diff -r) rather than a
(gzipped) tarball containing one patch for each changed file.


Cheers,

Nicolas

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

[Roman Müllenschläder-2]

Am Montag, 20. August 2007 schrieb Nicolas Boullis:

> Hi Roman (and others),
>
> On Mon, Aug 20, 2007 at 10:36:26AM +0200, Roman Müllenschläder wrote:
> > Hi List ;)
> >
> > As of newer dxr3-module versions support setting zoom factor via sysfs
> > (for to avoid losses due to overscan), it would be nice to even set zoom
> > without sysfs and to be able to set zoom dynamically ...
> >
> > Attached you'll find 2 patches for 0.16.3-rc4:
> >
> > zoom-module-param:
> > This one adds module parameter 'scr_zoom' to set zoom at loadtime
> >
> > zoom-ioctl:
> > This one adds possibility to set/get zoom via ioctl
> (...)
>
> > Newer driver versions support setting a zoom-factor via sysfs:
> > echo "90%" > "/sys/module/em8300/drivers/pci:Sigma Designs
> > EM8300/0000:02:00.0/zoom"
>
> I'd suggest
>   echo 90 > /sys/class/em8300/em8300-0/device/zoom
> as it is more straightforward (no need to know the PCI address of the
> device).

That would lead to a check for if sysfs is available, wouldn't it?

> > With the patches above one is able to set a zoom-factor even without
> > sysfs or changes to source (via module-param) or from within applications
> > like MMS (via config-option and ioctl) ;)
> >
> > It would be really nice if these changes could go upstream cause it makes
> > dxr3-modules more flexible. We (the people behind MMS) had a lot of
> > requests concerning overscan problems with dxr3. Setting a module-param
> > sets zoom-factor application-wide (MMS, VDR, etc.). But with the
> > possibility of ioctl-calls, each app is able to set it's own factor ;)
>
> As for the module parameter, this sounds like a good idea. Thanks.

Nice ... meaning it could be implemented?

> But I'm not really willing to add a new em8300-specific ioctl. The
> reason is that I'm willing to switch to a standard API in order to get
> included into linux. Adding a new ioctl certainly does not help this
> goal, but I'm all for implementing this through ioctl using a standard
> API if this is possible.

See what I can do ... what standard API are you aiming on? Are there different
ones? In what direction should we investigate?

> By the way, it looks like only MMS users complain about overscan. As far
> as I know, no xine or vdr user complained about such a problem. Any idea
> why?

No, not really ;)
Maybe it's because TV-Program is (more or less) designed for overscan and MMS
uses the whole picture without taking care of overscan?!

> > I'm not the author of the patches but I'm in contact with original author
> > ...
>
> I's meaningless, but I'd suggest tu use the unified diff format (most if
> not all free software developer I know prefer that format), and a single
> (possibly gzipped) patch (generated with diff -r) rather than a
> (gzipped) tarball containing one patch for each changed file.

Will prepare it next time ... I just posted it through ...

Thx
Roman

--

Homepage:
www.mymediasystem.org

Forum:
forum.mymediasystem.org

Wiki:
wiki.mymediasystem.org

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

[Nicolas Boullis]

Hi,

On Mon, Aug 20, 2007 at 11:52:56PM +0200, Roman Müllenschläder wrote:

> >
> > > Newer driver versions support setting a zoom-factor via sysfs:
> > > echo "90%" > "/sys/module/em8300/drivers/pci:Sigma Designs
> > > EM8300/0000:02:00.0/zoom"
> >
> > I'd suggest
> >   echo 90 > /sys/class/em8300/em8300-0/device/zoom
> > as it is more straightforward (no need to know the PCI address of the
> > device).
>
> That would lead to a check for if sysfs is available, wouldn't it?

Sorry, I fail to understand what you mean here.
Anyway, my suggestion was only meant as a replacement for your
  echo "90%" > "/sys/module/em8300/drivers/pci:Sigma Designs EM8300/0000:02:00.0/zoom"


> > As for the module parameter, this sounds like a good idea. Thanks.
>
> Nice ... meaning it could be implemented?

I guess so.


> > But I'm not really willing to add a new em8300-specific ioctl. The
> > reason is that I'm willing to switch to a standard API in order to get
> > included into linux. Adding a new ioctl certainly does not help this
> > goal, but I'm all for implementing this through ioctl using a standard
> > API if this is possible.
>
> See what I can do ... what standard API are you aiming on? Are there different
> ones? In what direction should we investigate?

If only I knew... It seems that the V4L2 API might be usable (and seems
to be used by the IVTV driver, which support PVR-350 boards which have
an hardware MPEG decoder, just like H+ and DXR3 boards).


> No, not really ;)
> Maybe it's because TV-Program is (more or less) designed for overscan and MMS
> uses the whole picture without taking care of overscan?!

That might be the explanation.


Cheers,

Nicolas

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

[Stas K]

Hi Nicolas,

> > > But I'm not really willing to add a new em8300-specific ioctl. The
> > > reason is that I'm willing to switch to a standard API in order to get
> > > included into linux. Adding a new ioctl certainly does not help this
> > > goal, but I'm all for implementing this through ioctl using a standard
> > > API if this is possible.
> 
> > See what I can do ... what standard API are you aiming on? Are there different 
> > ones? In what direction should we investigate?

> If only I knew... It seems that the V4L2 API might be usable (and seems 
> to be used by the IVTV driver, which support PVR-350 boards which have 
> an hardware MPEG decoder, just like H+ and DXR3 boards).


If you will remove some functions from the interface - it can affect other software using these functions, 
but what will wrong if you will add new fuction?
It is roughly DXR3 has same API with PVR-350 drivers at the IOCTL level.




Cheers,
Stas

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

[Nicolas Boullis]

Hi,

On Wed, Aug 22, 2007 at 08:40:41PM +0100, Stas K wrote:

> Hi Nicolas,
>
> > > > But I'm not really willing to add a new em8300-specific ioctl. The
> > > > reason is that I'm willing to switch to a standard API in order to get
> > > > included into linux. Adding a new ioctl certainly does not help this
> > > > goal, but I'm all for implementing this through ioctl using a standard
> > > > API if this is possible.
> >
> > > See what I can do ... what standard API are you aiming on? Are there different
> > > ones? In what direction should we investigate?
>
> > If only I knew... It seems that the V4L2 API might be usable (and seems
> > to be used by the IVTV driver, which support PVR-350 boards which have
> > an hardware MPEG decoder, just like H+ and DXR3 boards).
>
>
> If you will remove some functions from the interface - it can affect other software using these functions,
> but what will wrong if you will add new fuction?
> It is roughly DXR3 has same API with PVR-350 drivers at the IOCTL level.

I don't want to remove any function. If a feature can't be implemented
with standard ioctls, I have nothing against using an em8300-specific
ioctl, or suggestion to add a new "standard" ioctl.

I have no idea how the PVR350 driver works. All I think I have
understood is that its API changed recently to be merged into the linux
kernel. If you have some good knowledge, feel free to share it. And if
you can write code, feel free to send patches.


Cheers,

Nicolas

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel