* [PATCH 0/2] video: s3c-fb: Add window positioning support
@ 2011-08-25 19:51 ` Ajay Kumar
0 siblings, 0 replies; 35+ messages in thread
From: Ajay Kumar @ 2011-08-25 13:54 UTC (permalink / raw)
To: linux-arm-kernel
These patches are created against "for-next" branch of Kukjin Kim's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
This patch adds support for positioning of the FB windows on the LCD screen.
This patchset creates an ioctl and defines a data structure which are
specific to samsung SOCs, to hold the window position.
Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP
seem to be doing window/plane positioning in their driver code.
Is it possible to have this window positioning support at a common place?
For instance, we can have a common struture and ioctl number in
include/linux/fb.h as below:
#define FBIOPOS_OVERLAY_WIN _IOW('F', 0x21, struct fb_overlay_win_pos)
struct fb_overlay_win_pos {
__u32 win_pos_x; /* x-offset of window from LCD(0,0) */
__u32 win_pos_y; /* y-offset of window from LCD(0,0) */
};
where LCD(0,0) means the first pixel of the LCD screen.
Individual drivers can have implementation for this ioctl.
To Kukjin Kim,
[PATCH 1/2] ARM: SAMSUNG: Add Window Positioning Support for s3c-fb driver
To Paul Mundt, Florian Tobias Schandinat
[PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window positioning
arch/arm/plat-samsung/include/plat/fb.h | 14 +++++++++++
drivers/video/s3c-fb.c | 37 ++++++++++++++++++++++++++----
2 files changed, 46 insertions(+), 5 deletions(-)
^ permalink raw reply [flat|nested] 35+ messages in thread* [PATCH 0/2] video: s3c-fb: Add window positioning support
@ 2011-08-25 19:51 ` Ajay Kumar
0 siblings, 0 replies; 35+ messages in thread
From: Ajay Kumar @ 2011-08-25 19:51 UTC (permalink / raw)
To: linux-arm-kernel
These patches are created against "for-next" branch of Kukjin Kim's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
This patch adds support for positioning of the FB windows on the LCD screen.
This patchset creates an ioctl and defines a data structure which are
specific to samsung SOCs, to hold the window position.
Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP
seem to be doing window/plane positioning in their driver code.
Is it possible to have this window positioning support at a common place?
For instance, we can have a common struture and ioctl number in
include/linux/fb.h as below:
#define FBIOPOS_OVERLAY_WIN _IOW('F', 0x21, struct fb_overlay_win_pos)
struct fb_overlay_win_pos {
__u32 win_pos_x; /* x-offset of window from LCD(0,0) */
__u32 win_pos_y; /* y-offset of window from LCD(0,0) */
};
where LCD(0,0) means the first pixel of the LCD screen.
Individual drivers can have implementation for this ioctl.
To Kukjin Kim,
[PATCH 1/2] ARM: SAMSUNG: Add Window Positioning Support for s3c-fb driver
To Paul Mundt, Florian Tobias Schandinat
[PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window positioning
arch/arm/plat-samsung/include/plat/fb.h | 14 +++++++++++
drivers/video/s3c-fb.c | 37 ++++++++++++++++++++++++++----
2 files changed, 46 insertions(+), 5 deletions(-)
^ permalink raw reply [flat|nested] 35+ messages in thread* [PATCH 0/2] video: s3c-fb: Add window positioning support
@ 2011-08-25 19:51 ` Ajay Kumar
0 siblings, 0 replies; 35+ messages in thread
From: Ajay Kumar @ 2011-08-25 19:51 UTC (permalink / raw)
To: linux-samsung-soc, linux-fbdev, linux-arm-kernel
Cc: FlorianSchandinat, lethal, jg1.han, m.szyprowski, ben-linux,
banajit.g
These patches are created against "for-next" branch of Kukjin Kim's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
This patch adds support for positioning of the FB windows on the LCD screen.
This patchset creates an ioctl and defines a data structure which are
specific to samsung SOCs, to hold the window position.
Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP
seem to be doing window/plane positioning in their driver code.
Is it possible to have this window positioning support at a common place?
For instance, we can have a common struture and ioctl number in
include/linux/fb.h as below:
#define FBIOPOS_OVERLAY_WIN _IOW('F', 0x21, struct fb_overlay_win_pos)
struct fb_overlay_win_pos {
__u32 win_pos_x; /* x-offset of window from LCD(0,0) */
__u32 win_pos_y; /* y-offset of window from LCD(0,0) */
};
where LCD(0,0) means the first pixel of the LCD screen.
Individual drivers can have implementation for this ioctl.
To Kukjin Kim,
[PATCH 1/2] ARM: SAMSUNG: Add Window Positioning Support for s3c-fb driver
To Paul Mundt, Florian Tobias Schandinat
[PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window positioning
arch/arm/plat-samsung/include/plat/fb.h | 14 +++++++++++
drivers/video/s3c-fb.c | 37 ++++++++++++++++++++++++++----
2 files changed, 46 insertions(+), 5 deletions(-)
^ permalink raw reply [flat|nested] 35+ messages in thread* [PATCH 1/2] ARM: SAMSUNG: Add Window Positioning Support for s3c-fb
2011-08-25 19:51 ` Ajay Kumar
(?)
@ 2011-08-25 19:51 ` Ajay Kumar
-1 siblings, 0 replies; 35+ messages in thread
From: Ajay Kumar @ 2011-08-25 13:54 UTC (permalink / raw)
To: linux-arm-kernel
This patch:
--adds a data-structure to hold the current position of windows.
--adds an ioctl number to support dynamic positioning the windows.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
---
arch/arm/plat-samsung/include/plat/fb.h | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/fb.h b/arch/arm/plat-samsung/include/plat/fb.h
index bd79c0a..77ed75c 100644
--- a/arch/arm/plat-samsung/include/plat/fb.h
+++ b/arch/arm/plat-samsung/include/plat/fb.h
@@ -22,6 +22,18 @@
*/
#define S3C_FB_MAX_WIN (5)
+/* struct s3cfb_window_pos
+ * @win_pos_x: X-coordinate of window from the left.
+ * @win_pos_y: Y-coordinate of window from the top.
+ */
+struct s3cfb_window_pos {
+ int win_pos_x;
+ int win_pos_y;
+};
+
+/* Custom ioctl */
+#define S3CFB_WIN_POSITION _IOW('F', 1, struct s3cfb_window_pos)
+
/**
* struct s3c_fb_pd_win - per window setup data
* @win_mode: The display parameters to initialise (not for window 0)
@@ -35,6 +47,8 @@ struct s3c_fb_pd_win {
unsigned short max_bpp;
unsigned short virtual_x;
unsigned short virtual_y;
+
+ struct s3cfb_window_pos winpos;
};
/**
--
1.7.0.4
^ permalink raw reply related [flat|nested] 35+ messages in thread* [PATCH 1/2] ARM: SAMSUNG: Add Window Positioning Support for s3c-fb driver
@ 2011-08-25 19:51 ` Ajay Kumar
0 siblings, 0 replies; 35+ messages in thread
From: Ajay Kumar @ 2011-08-25 19:51 UTC (permalink / raw)
To: linux-arm-kernel
This patch:
--adds a data-structure to hold the current position of windows.
--adds an ioctl number to support dynamic positioning the windows.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
---
arch/arm/plat-samsung/include/plat/fb.h | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/fb.h b/arch/arm/plat-samsung/include/plat/fb.h
index bd79c0a..77ed75c 100644
--- a/arch/arm/plat-samsung/include/plat/fb.h
+++ b/arch/arm/plat-samsung/include/plat/fb.h
@@ -22,6 +22,18 @@
*/
#define S3C_FB_MAX_WIN (5)
+/* struct s3cfb_window_pos
+ * @win_pos_x: X-coordinate of window from the left.
+ * @win_pos_y: Y-coordinate of window from the top.
+ */
+struct s3cfb_window_pos {
+ int win_pos_x;
+ int win_pos_y;
+};
+
+/* Custom ioctl */
+#define S3CFB_WIN_POSITION _IOW('F', 1, struct s3cfb_window_pos)
+
/**
* struct s3c_fb_pd_win - per window setup data
* @win_mode: The display parameters to initialise (not for window 0)
@@ -35,6 +47,8 @@ struct s3c_fb_pd_win {
unsigned short max_bpp;
unsigned short virtual_x;
unsigned short virtual_y;
+
+ struct s3cfb_window_pos winpos;
};
/**
--
1.7.0.4
^ permalink raw reply related [flat|nested] 35+ messages in thread* [PATCH 1/2] ARM: SAMSUNG: Add Window Positioning Support for s3c-fb driver
@ 2011-08-25 19:51 ` Ajay Kumar
0 siblings, 0 replies; 35+ messages in thread
From: Ajay Kumar @ 2011-08-25 19:51 UTC (permalink / raw)
To: linux-samsung-soc, linux-fbdev, linux-arm-kernel
Cc: FlorianSchandinat, lethal, jg1.han, m.szyprowski, ben-linux,
banajit.g
This patch:
--adds a data-structure to hold the current position of windows.
--adds an ioctl number to support dynamic positioning the windows.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
---
arch/arm/plat-samsung/include/plat/fb.h | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/fb.h b/arch/arm/plat-samsung/include/plat/fb.h
index bd79c0a..77ed75c 100644
--- a/arch/arm/plat-samsung/include/plat/fb.h
+++ b/arch/arm/plat-samsung/include/plat/fb.h
@@ -22,6 +22,18 @@
*/
#define S3C_FB_MAX_WIN (5)
+/* struct s3cfb_window_pos
+ * @win_pos_x: X-coordinate of window from the left.
+ * @win_pos_y: Y-coordinate of window from the top.
+ */
+struct s3cfb_window_pos {
+ int win_pos_x;
+ int win_pos_y;
+};
+
+/* Custom ioctl */
+#define S3CFB_WIN_POSITION _IOW('F', 1, struct s3cfb_window_pos)
+
/**
* struct s3c_fb_pd_win - per window setup data
* @win_mode: The display parameters to initialise (not for window 0)
@@ -35,6 +47,8 @@ struct s3c_fb_pd_win {
unsigned short max_bpp;
unsigned short virtual_x;
unsigned short virtual_y;
+
+ struct s3cfb_window_pos winpos;
};
/**
--
1.7.0.4
^ permalink raw reply related [flat|nested] 35+ messages in thread
* [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window
2011-08-25 19:51 ` Ajay Kumar
(?)
@ 2011-08-25 19:51 ` Ajay Kumar
-1 siblings, 0 replies; 35+ messages in thread
From: Ajay Kumar @ 2011-08-25 13:54 UTC (permalink / raw)
To: linux-arm-kernel
This patch modifies the existing s3c-fb driver to provide
flexibility to the user to reposition the framebuffer windows.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
---
drivers/video/s3c-fb.c | 37 ++++++++++++++++++++++++++++++++-----
1 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 0fda252..41179d7 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -442,6 +442,7 @@ static int s3c_fb_set_par(struct fb_info *info)
struct fb_var_screeninfo *var = &info->var;
struct s3c_fb_win *win = info->par;
struct s3c_fb *sfb = win->parent;
+ struct s3cfb_window_pos *winpos = &win->windata->winpos;
void __iomem *regs = sfb->regs;
void __iomem *buf = regs;
int win_no = win->index;
@@ -539,12 +540,13 @@ static int s3c_fb_set_par(struct fb_info *info)
/* write 'OSD' registers to control position of framebuffer */
- data = VIDOSDxA_TOPLEFT_X(0) | VIDOSDxA_TOPLEFT_Y(0);
+ data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
+ VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
writel(data, regs + VIDOSD_A(win_no, sfb->variant));
- data = VIDOSDxB_BOTRIGHT_X(s3c_fb_align_word(var->bits_per_pixel,
- var->xres - 1)) |
- VIDOSDxB_BOTRIGHT_Y(var->yres - 1);
+ data = VIDOSDxB_BOTRIGHT_X((s3c_fb_align_word(var->bits_per_pixel,
+ (winpos->win_pos_x + var->xres - 1)))) |
+ VIDOSDxB_BOTRIGHT_Y((winpos->win_pos_y + var->yres - 1));
writel(data, regs + VIDOSD_B(win_no, sfb->variant));
@@ -999,8 +1001,10 @@ static int s3c_fb_ioctl(struct fb_info *info, unsigned int cmd,
{
struct s3c_fb_win *win = info->par;
struct s3c_fb *sfb = win->parent;
- int ret;
+ struct s3cfb_window_pos *winpos = &win->windata->winpos;
+ int ret = 0;
u32 crtc;
+ u32 data;
switch (cmd) {
case FBIO_WAITFORVSYNC:
@@ -1011,6 +1015,29 @@ static int s3c_fb_ioctl(struct fb_info *info, unsigned int cmd,
ret = s3c_fb_wait_for_vsync(sfb, crtc);
break;
+ case S3CFB_WIN_POSITION:
+ if (copy_from_user(winpos, (u32 __user *)arg,
+ sizeof(struct s3cfb_window_pos))) {
+ ret = -EFAULT;
+ break;
+ }
+
+ shadow_protect_win(win, 1);
+
+ /* write 'OSD' registers to set position of the window */
+ data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
+ VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
+ writel(data, sfb->regs + VIDOSD_A(win->index, sfb->variant));
+
+ data = VIDOSDxB_BOTRIGHT_X(
+ s3c_fb_align_word(info->var.bits_per_pixel,
+ (winpos->win_pos_x + info->var.xres - 1)));
+ data |= VIDOSDxB_BOTRIGHT_Y(winpos->win_pos_y +
+ info->var.yres - 1);
+ writel(data, sfb->regs + VIDOSD_B(win->index, sfb->variant));
+
+ shadow_protect_win(win, 0);
+ break;
default:
ret = -ENOTTY;
}
--
1.7.0.4
^ permalink raw reply related [flat|nested] 35+ messages in thread* [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window positioning
@ 2011-08-25 19:51 ` Ajay Kumar
0 siblings, 0 replies; 35+ messages in thread
From: Ajay Kumar @ 2011-08-25 19:51 UTC (permalink / raw)
To: linux-arm-kernel
This patch modifies the existing s3c-fb driver to provide
flexibility to the user to reposition the framebuffer windows.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
---
drivers/video/s3c-fb.c | 37 ++++++++++++++++++++++++++++++++-----
1 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 0fda252..41179d7 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -442,6 +442,7 @@ static int s3c_fb_set_par(struct fb_info *info)
struct fb_var_screeninfo *var = &info->var;
struct s3c_fb_win *win = info->par;
struct s3c_fb *sfb = win->parent;
+ struct s3cfb_window_pos *winpos = &win->windata->winpos;
void __iomem *regs = sfb->regs;
void __iomem *buf = regs;
int win_no = win->index;
@@ -539,12 +540,13 @@ static int s3c_fb_set_par(struct fb_info *info)
/* write 'OSD' registers to control position of framebuffer */
- data = VIDOSDxA_TOPLEFT_X(0) | VIDOSDxA_TOPLEFT_Y(0);
+ data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
+ VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
writel(data, regs + VIDOSD_A(win_no, sfb->variant));
- data = VIDOSDxB_BOTRIGHT_X(s3c_fb_align_word(var->bits_per_pixel,
- var->xres - 1)) |
- VIDOSDxB_BOTRIGHT_Y(var->yres - 1);
+ data = VIDOSDxB_BOTRIGHT_X((s3c_fb_align_word(var->bits_per_pixel,
+ (winpos->win_pos_x + var->xres - 1)))) |
+ VIDOSDxB_BOTRIGHT_Y((winpos->win_pos_y + var->yres - 1));
writel(data, regs + VIDOSD_B(win_no, sfb->variant));
@@ -999,8 +1001,10 @@ static int s3c_fb_ioctl(struct fb_info *info, unsigned int cmd,
{
struct s3c_fb_win *win = info->par;
struct s3c_fb *sfb = win->parent;
- int ret;
+ struct s3cfb_window_pos *winpos = &win->windata->winpos;
+ int ret = 0;
u32 crtc;
+ u32 data;
switch (cmd) {
case FBIO_WAITFORVSYNC:
@@ -1011,6 +1015,29 @@ static int s3c_fb_ioctl(struct fb_info *info, unsigned int cmd,
ret = s3c_fb_wait_for_vsync(sfb, crtc);
break;
+ case S3CFB_WIN_POSITION:
+ if (copy_from_user(winpos, (u32 __user *)arg,
+ sizeof(struct s3cfb_window_pos))) {
+ ret = -EFAULT;
+ break;
+ }
+
+ shadow_protect_win(win, 1);
+
+ /* write 'OSD' registers to set position of the window */
+ data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
+ VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
+ writel(data, sfb->regs + VIDOSD_A(win->index, sfb->variant));
+
+ data = VIDOSDxB_BOTRIGHT_X(
+ s3c_fb_align_word(info->var.bits_per_pixel,
+ (winpos->win_pos_x + info->var.xres - 1)));
+ data |= VIDOSDxB_BOTRIGHT_Y(winpos->win_pos_y +
+ info->var.yres - 1);
+ writel(data, sfb->regs + VIDOSD_B(win->index, sfb->variant));
+
+ shadow_protect_win(win, 0);
+ break;
default:
ret = -ENOTTY;
}
--
1.7.0.4
^ permalink raw reply related [flat|nested] 35+ messages in thread* [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window positioning
@ 2011-08-25 19:51 ` Ajay Kumar
0 siblings, 0 replies; 35+ messages in thread
From: Ajay Kumar @ 2011-08-25 19:51 UTC (permalink / raw)
To: linux-samsung-soc, linux-fbdev, linux-arm-kernel
Cc: FlorianSchandinat, lethal, jg1.han, m.szyprowski, ben-linux,
banajit.g
This patch modifies the existing s3c-fb driver to provide
flexibility to the user to reposition the framebuffer windows.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
---
drivers/video/s3c-fb.c | 37 ++++++++++++++++++++++++++++++++-----
1 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 0fda252..41179d7 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -442,6 +442,7 @@ static int s3c_fb_set_par(struct fb_info *info)
struct fb_var_screeninfo *var = &info->var;
struct s3c_fb_win *win = info->par;
struct s3c_fb *sfb = win->parent;
+ struct s3cfb_window_pos *winpos = &win->windata->winpos;
void __iomem *regs = sfb->regs;
void __iomem *buf = regs;
int win_no = win->index;
@@ -539,12 +540,13 @@ static int s3c_fb_set_par(struct fb_info *info)
/* write 'OSD' registers to control position of framebuffer */
- data = VIDOSDxA_TOPLEFT_X(0) | VIDOSDxA_TOPLEFT_Y(0);
+ data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
+ VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
writel(data, regs + VIDOSD_A(win_no, sfb->variant));
- data = VIDOSDxB_BOTRIGHT_X(s3c_fb_align_word(var->bits_per_pixel,
- var->xres - 1)) |
- VIDOSDxB_BOTRIGHT_Y(var->yres - 1);
+ data = VIDOSDxB_BOTRIGHT_X((s3c_fb_align_word(var->bits_per_pixel,
+ (winpos->win_pos_x + var->xres - 1)))) |
+ VIDOSDxB_BOTRIGHT_Y((winpos->win_pos_y + var->yres - 1));
writel(data, regs + VIDOSD_B(win_no, sfb->variant));
@@ -999,8 +1001,10 @@ static int s3c_fb_ioctl(struct fb_info *info, unsigned int cmd,
{
struct s3c_fb_win *win = info->par;
struct s3c_fb *sfb = win->parent;
- int ret;
+ struct s3cfb_window_pos *winpos = &win->windata->winpos;
+ int ret = 0;
u32 crtc;
+ u32 data;
switch (cmd) {
case FBIO_WAITFORVSYNC:
@@ -1011,6 +1015,29 @@ static int s3c_fb_ioctl(struct fb_info *info, unsigned int cmd,
ret = s3c_fb_wait_for_vsync(sfb, crtc);
break;
+ case S3CFB_WIN_POSITION:
+ if (copy_from_user(winpos, (u32 __user *)arg,
+ sizeof(struct s3cfb_window_pos))) {
+ ret = -EFAULT;
+ break;
+ }
+
+ shadow_protect_win(win, 1);
+
+ /* write 'OSD' registers to set position of the window */
+ data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
+ VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
+ writel(data, sfb->regs + VIDOSD_A(win->index, sfb->variant));
+
+ data = VIDOSDxB_BOTRIGHT_X(
+ s3c_fb_align_word(info->var.bits_per_pixel,
+ (winpos->win_pos_x + info->var.xres - 1)));
+ data |= VIDOSDxB_BOTRIGHT_Y(winpos->win_pos_y +
+ info->var.yres - 1);
+ writel(data, sfb->regs + VIDOSD_B(win->index, sfb->variant));
+
+ shadow_protect_win(win, 0);
+ break;
default:
ret = -ENOTTY;
}
--
1.7.0.4
^ permalink raw reply related [flat|nested] 35+ messages in thread
* Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
2011-08-25 19:51 ` Ajay Kumar
(?)
@ 2011-09-01 16:45 ` Florian Tobias Schandinat
-1 siblings, 0 replies; 35+ messages in thread
From: Florian Tobias Schandinat @ 2011-09-01 16:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
On 08/25/2011 07:51 PM, Ajay Kumar wrote:
> Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP
> seem to be doing window/plane positioning in their driver code.
> Is it possible to have this window positioning support at a common place?
Good point. Congratulations for figuring out that I like to standardize things.
But I think your suggestion is far from being enough to be useful for userspace
(which is our goal so that applications can be reused along drivers and don't
need to know about individual drivers).
So let me at first summarize how I understand you implemented those things after
having a brief look at some of the drivers:
Windows are rectangular screen areas whose pixel data come from other locations.
The other locations are accessible via other framebuffer devices (e.g. fb1). So
in this area the data of fb1 is shown and not the data of fb0 that would be
normally shown.
So in addition to your proposed positioning I think we should also have the
following to give userspace a useful set of functionality:
- a way to discover how the screen is composited (how many windows are there,
how they are stacked and how to access those)
- a way to enable/disable windows (make them (in)visible)
- reporting and selecting how the window content can be mixed with the root
screen (overwrite, source or destination color keying)
- things like window size and color format could be handled by the usual fb API
used on the window. However there might be restrictions which cause them to be
not 100% API compatible (for example when changing the color format if the
windows are required to have the same format as the root screen)
- do we need to worry about hardware (up/down) scaling of the window content?
So is that what you need for a standardized window implementation?
Any additional things that were useful/needed in this context?
Would you consider adding support for this API in your drivers? (as
standardizing wouldn't be useful if nobody would implement it)
Best regards,
Florian Tobias Schandinat
>
> For instance, we can have a common struture and ioctl number in
> include/linux/fb.h as below:
>
> #define FBIOPOS_OVERLAY_WIN _IOW('F', 0x21, struct fb_overlay_win_pos)
>
> struct fb_overlay_win_pos {
> __u32 win_pos_x; /* x-offset of window from LCD(0,0) */
> __u32 win_pos_y; /* y-offset of window from LCD(0,0) */
> };
>
> where LCD(0,0) means the first pixel of the LCD screen.
> Individual drivers can have implementation for this ioctl.
>
> To Kukjin Kim,
> [PATCH 1/2] ARM: SAMSUNG: Add Window Positioning Support for s3c-fb driver
>
> To Paul Mundt, Florian Tobias Schandinat
> [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window positioning
>
> arch/arm/plat-samsung/include/plat/fb.h | 14 +++++++++++
> drivers/video/s3c-fb.c | 37 ++++++++++++++++++++++++++----
> 2 files changed, 46 insertions(+), 5 deletions(-)
>
>
^ permalink raw reply [flat|nested] 35+ messages in thread* [PATCH 0/2] video: s3c-fb: Add window positioning support
@ 2011-09-01 16:45 ` Florian Tobias Schandinat
0 siblings, 0 replies; 35+ messages in thread
From: Florian Tobias Schandinat @ 2011-09-01 16:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
On 08/25/2011 07:51 PM, Ajay Kumar wrote:
> Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP
> seem to be doing window/plane positioning in their driver code.
> Is it possible to have this window positioning support at a common place?
Good point. Congratulations for figuring out that I like to standardize things.
But I think your suggestion is far from being enough to be useful for userspace
(which is our goal so that applications can be reused along drivers and don't
need to know about individual drivers).
So let me at first summarize how I understand you implemented those things after
having a brief look at some of the drivers:
Windows are rectangular screen areas whose pixel data come from other locations.
The other locations are accessible via other framebuffer devices (e.g. fb1). So
in this area the data of fb1 is shown and not the data of fb0 that would be
normally shown.
So in addition to your proposed positioning I think we should also have the
following to give userspace a useful set of functionality:
- a way to discover how the screen is composited (how many windows are there,
how they are stacked and how to access those)
- a way to enable/disable windows (make them (in)visible)
- reporting and selecting how the window content can be mixed with the root
screen (overwrite, source or destination color keying)
- things like window size and color format could be handled by the usual fb API
used on the window. However there might be restrictions which cause them to be
not 100% API compatible (for example when changing the color format if the
windows are required to have the same format as the root screen)
- do we need to worry about hardware (up/down) scaling of the window content?
So is that what you need for a standardized window implementation?
Any additional things that were useful/needed in this context?
Would you consider adding support for this API in your drivers? (as
standardizing wouldn't be useful if nobody would implement it)
Best regards,
Florian Tobias Schandinat
>
> For instance, we can have a common struture and ioctl number in
> include/linux/fb.h as below:
>
> #define FBIOPOS_OVERLAY_WIN _IOW('F', 0x21, struct fb_overlay_win_pos)
>
> struct fb_overlay_win_pos {
> __u32 win_pos_x; /* x-offset of window from LCD(0,0) */
> __u32 win_pos_y; /* y-offset of window from LCD(0,0) */
> };
>
> where LCD(0,0) means the first pixel of the LCD screen.
> Individual drivers can have implementation for this ioctl.
>
> To Kukjin Kim,
> [PATCH 1/2] ARM: SAMSUNG: Add Window Positioning Support for s3c-fb driver
>
> To Paul Mundt, Florian Tobias Schandinat
> [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window positioning
>
> arch/arm/plat-samsung/include/plat/fb.h | 14 +++++++++++
> drivers/video/s3c-fb.c | 37 ++++++++++++++++++++++++++----
> 2 files changed, 46 insertions(+), 5 deletions(-)
>
>
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
@ 2011-09-01 16:45 ` Florian Tobias Schandinat
0 siblings, 0 replies; 35+ messages in thread
From: Florian Tobias Schandinat @ 2011-09-01 16:45 UTC (permalink / raw)
To: Ajay Kumar
Cc: linux-samsung-soc, linux-fbdev, linux-arm-kernel, lethal, jg1.han,
m.szyprowski, ben-linux, banajit.g, Manuel Lauss, Tomi Valkeinen
Hi all,
On 08/25/2011 07:51 PM, Ajay Kumar wrote:
> Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP
> seem to be doing window/plane positioning in their driver code.
> Is it possible to have this window positioning support at a common place?
Good point. Congratulations for figuring out that I like to standardize things.
But I think your suggestion is far from being enough to be useful for userspace
(which is our goal so that applications can be reused along drivers and don't
need to know about individual drivers).
So let me at first summarize how I understand you implemented those things after
having a brief look at some of the drivers:
Windows are rectangular screen areas whose pixel data come from other locations.
The other locations are accessible via other framebuffer devices (e.g. fb1). So
in this area the data of fb1 is shown and not the data of fb0 that would be
normally shown.
So in addition to your proposed positioning I think we should also have the
following to give userspace a useful set of functionality:
- a way to discover how the screen is composited (how many windows are there,
how they are stacked and how to access those)
- a way to enable/disable windows (make them (in)visible)
- reporting and selecting how the window content can be mixed with the root
screen (overwrite, source or destination color keying)
- things like window size and color format could be handled by the usual fb API
used on the window. However there might be restrictions which cause them to be
not 100% API compatible (for example when changing the color format if the
windows are required to have the same format as the root screen)
- do we need to worry about hardware (up/down) scaling of the window content?
So is that what you need for a standardized window implementation?
Any additional things that were useful/needed in this context?
Would you consider adding support for this API in your drivers? (as
standardizing wouldn't be useful if nobody would implement it)
Best regards,
Florian Tobias Schandinat
>
> For instance, we can have a common struture and ioctl number in
> include/linux/fb.h as below:
>
> #define FBIOPOS_OVERLAY_WIN _IOW('F', 0x21, struct fb_overlay_win_pos)
>
> struct fb_overlay_win_pos {
> __u32 win_pos_x; /* x-offset of window from LCD(0,0) */
> __u32 win_pos_y; /* y-offset of window from LCD(0,0) */
> };
>
> where LCD(0,0) means the first pixel of the LCD screen.
> Individual drivers can have implementation for this ioctl.
>
> To Kukjin Kim,
> [PATCH 1/2] ARM: SAMSUNG: Add Window Positioning Support for s3c-fb driver
>
> To Paul Mundt, Florian Tobias Schandinat
> [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window positioning
>
> arch/arm/plat-samsung/include/plat/fb.h | 14 +++++++++++
> drivers/video/s3c-fb.c | 37 ++++++++++++++++++++++++++----
> 2 files changed, 46 insertions(+), 5 deletions(-)
>
>
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
2011-09-01 16:45 ` Florian Tobias Schandinat
(?)
@ 2011-09-02 9:58 ` Tomi Valkeinen
-1 siblings, 0 replies; 35+ messages in thread
From: Tomi Valkeinen @ 2011-09-02 9:58 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Thu, 2011-09-01 at 16:45 +0000, Florian Tobias Schandinat wrote:
> Hi all,
>
> On 08/25/2011 07:51 PM, Ajay Kumar wrote:
> > Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP
> > seem to be doing window/plane positioning in their driver code.
> > Is it possible to have this window positioning support at a common place?
>
> Good point. Congratulations for figuring out that I like to standardize things.
> But I think your suggestion is far from being enough to be useful for userspace
> (which is our goal so that applications can be reused along drivers and don't
> need to know about individual drivers).
>
> So let me at first summarize how I understand you implemented those things after
> having a brief look at some of the drivers:
> Windows are rectangular screen areas whose pixel data come from other locations.
> The other locations are accessible via other framebuffer devices (e.g. fb1). So
> in this area the data of fb1 is shown and not the data of fb0 that would be
> normally shown.
Here's what we have on OMAP:
We have a bunch of hardware overlays, each of which can go to one
output. When using fbdev, the pixel data for overlays comes from the
framebuffers. One fb can be used as a pixel source for multiple
overlays.
So, for example, the "connections" can be like these:
Initial configuration
.-----. .------. .------.
| fb0 |-------->| ovl0 |-----.---->| LCD |
'-----' '------' | '------'
.-----. .------. |
| fb1 |-------->| ovl1 |-----|
'-----' '------' |
.-----. .------. | .------.
| fb2 |-------->| ovl2 |-----' | TV |
'-----' '------' '------'
Video on fb1, shown on LCD and TV
.-----. .------. .------.
| fb0 |-------->| ovl0 |-----.---->| LCD |
'-----' '------' | '------'
.-----. .------. |
| fb1 |----.--->| ovl1 |-----'
'-----' | '------'
.-----. | .------. .------.
| fb2 | '--->| ovl2 |---------->| TV |
'-----' '------' '------'
And how the actual image is composited on the display, we have first the
fb side (no news there):
.---------------------fb-vxres---------------------.
| |
| |
| (xoffset,yoffset) |
| .-------fb-xres------------. |
f | | |
b f | |
| b | |
v | | |
y y | |
r r | |
e e | |
s s | |
| | | |
| '--------------------------' |
| |
| |
'--------------------------------------------------'
The area marked by x/yoffset and x/yres is used as the pixel source for
the overlay.
On the display we have something like this:
.----------------disp-xres----------------.
| |
| (xpos,ypos) |
| .-----ovl-xres-----. |
d | | |
i o | |
s v | |
p l | |
| | | |
y y | |
r r | |
e e | |
s s | |
| | | |
| '------------------' |
| |
'-----------------------------------------'
The x/ypos of the overlay does not have any relation to the x/yoffset of
the framebuffer. The overlay's x/yres is the same as the fb's x/yres in
case the overlay doesn't support scaling (OMAP's case this is true for
overlay0). Otherwise the overlay's x/yres is only limited by the HW's
scaling capabilities.
The overlays have a priority order, and where there's no overlay, a
background color is used. So like this:
.-----------------------------------------.
| background color |
| .-----------------------. |
| | ovl0 | |
| | | |
| | .--------------. | |
| | | ovl1 | | |
| | | | | |
| | | .-------------------. |
| | | | ovl2 | |
| | '--------| | |
| '----------| | |
| | | |
| | | |
| | | |
| '-------------------' |
'-----------------------------------------'
As you may have noticed, this raises in annoying problem: the
framebuffer does not represent the display, and thus the display related
information in the fb, like video timings, are difficult or impossible
to use. I haven't found any solution to this.
> So in addition to your proposed positioning I think we should also have the
> following to give userspace a useful set of functionality:
>
> - a way to discover how the screen is composited (how many windows are there,
> how they are stacked and how to access those)
>
> - a way to enable/disable windows (make them (in)visible)
>
> - reporting and selecting how the window content can be mixed with the root
> screen (overwrite, source or destination color keying)
Right, and there may not be a root screen at all, like on OMAP. (if the
background color doesn't count as a root screen).
> - things like window size and color format could be handled by the usual fb API
> used on the window. However there might be restrictions which cause them to be
> not 100% API compatible (for example when changing the color format if the
> windows are required to have the same format as the root screen)
>
> - do we need to worry about hardware (up/down) scaling of the window content?
>
>
> So is that what you need for a standardized window implementation?
> Any additional things that were useful/needed in this context?
> Would you consider adding support for this API in your drivers? (as
> standardizing wouldn't be useful if nobody would implement it)
We already have the current implementation in omapfb, so while a
standard API would be nice, we still need to keep the old custom API for
compatibility.
Another thing is that I'm not sure how much features we should try to
add to fbdev. The fbdev model is a bit limited (for example, the timings
problem above, or double/triple buffering), and at least we are
currently looking at using DRM. There will still be a framebuffer, but
that's mostly for fbconsole and such, and doesn't need to support
overlays, scaling, and other more complex features.
Tomi
^ permalink raw reply [flat|nested] 35+ messages in thread* [PATCH 0/2] video: s3c-fb: Add window positioning support
@ 2011-09-02 9:58 ` Tomi Valkeinen
0 siblings, 0 replies; 35+ messages in thread
From: Tomi Valkeinen @ 2011-09-02 9:58 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Thu, 2011-09-01 at 16:45 +0000, Florian Tobias Schandinat wrote:
> Hi all,
>
> On 08/25/2011 07:51 PM, Ajay Kumar wrote:
> > Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP
> > seem to be doing window/plane positioning in their driver code.
> > Is it possible to have this window positioning support at a common place?
>
> Good point. Congratulations for figuring out that I like to standardize things.
> But I think your suggestion is far from being enough to be useful for userspace
> (which is our goal so that applications can be reused along drivers and don't
> need to know about individual drivers).
>
> So let me at first summarize how I understand you implemented those things after
> having a brief look at some of the drivers:
> Windows are rectangular screen areas whose pixel data come from other locations.
> The other locations are accessible via other framebuffer devices (e.g. fb1). So
> in this area the data of fb1 is shown and not the data of fb0 that would be
> normally shown.
Here's what we have on OMAP:
We have a bunch of hardware overlays, each of which can go to one
output. When using fbdev, the pixel data for overlays comes from the
framebuffers. One fb can be used as a pixel source for multiple
overlays.
So, for example, the "connections" can be like these:
Initial configuration
.-----. .------. .------.
| fb0 |-------->| ovl0 |-----.---->| LCD |
'-----' '------' | '------'
.-----. .------. |
| fb1 |-------->| ovl1 |-----|
'-----' '------' |
.-----. .------. | .------.
| fb2 |-------->| ovl2 |-----' | TV |
'-----' '------' '------'
Video on fb1, shown on LCD and TV
.-----. .------. .------.
| fb0 |-------->| ovl0 |-----.---->| LCD |
'-----' '------' | '------'
.-----. .------. |
| fb1 |----.--->| ovl1 |-----'
'-----' | '------'
.-----. | .------. .------.
| fb2 | '--->| ovl2 |---------->| TV |
'-----' '------' '------'
And how the actual image is composited on the display, we have first the
fb side (no news there):
.---------------------fb-vxres---------------------.
| |
| |
| (xoffset,yoffset) |
| .-------fb-xres------------. |
f | | |
b f | |
| b | |
v | | |
y y | |
r r | |
e e | |
s s | |
| | | |
| '--------------------------' |
| |
| |
'--------------------------------------------------'
The area marked by x/yoffset and x/yres is used as the pixel source for
the overlay.
On the display we have something like this:
.----------------disp-xres----------------.
| |
| (xpos,ypos) |
| .-----ovl-xres-----. |
d | | |
i o | |
s v | |
p l | |
| | | |
y y | |
r r | |
e e | |
s s | |
| | | |
| '------------------' |
| |
'-----------------------------------------'
The x/ypos of the overlay does not have any relation to the x/yoffset of
the framebuffer. The overlay's x/yres is the same as the fb's x/yres in
case the overlay doesn't support scaling (OMAP's case this is true for
overlay0). Otherwise the overlay's x/yres is only limited by the HW's
scaling capabilities.
The overlays have a priority order, and where there's no overlay, a
background color is used. So like this:
.-----------------------------------------.
| background color |
| .-----------------------. |
| | ovl0 | |
| | | |
| | .--------------. | |
| | | ovl1 | | |
| | | | | |
| | | .-------------------. |
| | | | ovl2 | |
| | '--------| | |
| '----------| | |
| | | |
| | | |
| | | |
| '-------------------' |
'-----------------------------------------'
As you may have noticed, this raises in annoying problem: the
framebuffer does not represent the display, and thus the display related
information in the fb, like video timings, are difficult or impossible
to use. I haven't found any solution to this.
> So in addition to your proposed positioning I think we should also have the
> following to give userspace a useful set of functionality:
>
> - a way to discover how the screen is composited (how many windows are there,
> how they are stacked and how to access those)
>
> - a way to enable/disable windows (make them (in)visible)
>
> - reporting and selecting how the window content can be mixed with the root
> screen (overwrite, source or destination color keying)
Right, and there may not be a root screen at all, like on OMAP. (if the
background color doesn't count as a root screen).
> - things like window size and color format could be handled by the usual fb API
> used on the window. However there might be restrictions which cause them to be
> not 100% API compatible (for example when changing the color format if the
> windows are required to have the same format as the root screen)
>
> - do we need to worry about hardware (up/down) scaling of the window content?
>
>
> So is that what you need for a standardized window implementation?
> Any additional things that were useful/needed in this context?
> Would you consider adding support for this API in your drivers? (as
> standardizing wouldn't be useful if nobody would implement it)
We already have the current implementation in omapfb, so while a
standard API would be nice, we still need to keep the old custom API for
compatibility.
Another thing is that I'm not sure how much features we should try to
add to fbdev. The fbdev model is a bit limited (for example, the timings
problem above, or double/triple buffering), and at least we are
currently looking at using DRM. There will still be a framebuffer, but
that's mostly for fbconsole and such, and doesn't need to support
overlays, scaling, and other more complex features.
Tomi
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
@ 2011-09-02 9:58 ` Tomi Valkeinen
0 siblings, 0 replies; 35+ messages in thread
From: Tomi Valkeinen @ 2011-09-02 9:58 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: linux-fbdev, linux-samsung-soc, banajit.g, jg1.han, Manuel Lauss,
lethal, ben-linux, Ajay Kumar, linux-arm-kernel, m.szyprowski
Hi,
On Thu, 2011-09-01 at 16:45 +0000, Florian Tobias Schandinat wrote:
> Hi all,
>
> On 08/25/2011 07:51 PM, Ajay Kumar wrote:
> > Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP
> > seem to be doing window/plane positioning in their driver code.
> > Is it possible to have this window positioning support at a common place?
>
> Good point. Congratulations for figuring out that I like to standardize things.
> But I think your suggestion is far from being enough to be useful for userspace
> (which is our goal so that applications can be reused along drivers and don't
> need to know about individual drivers).
>
> So let me at first summarize how I understand you implemented those things after
> having a brief look at some of the drivers:
> Windows are rectangular screen areas whose pixel data come from other locations.
> The other locations are accessible via other framebuffer devices (e.g. fb1). So
> in this area the data of fb1 is shown and not the data of fb0 that would be
> normally shown.
Here's what we have on OMAP:
We have a bunch of hardware overlays, each of which can go to one
output. When using fbdev, the pixel data for overlays comes from the
framebuffers. One fb can be used as a pixel source for multiple
overlays.
So, for example, the "connections" can be like these:
Initial configuration
.-----. .------. .------.
| fb0 |-------->| ovl0 |-----.---->| LCD |
'-----' '------' | '------'
.-----. .------. |
| fb1 |-------->| ovl1 |-----|
'-----' '------' |
.-----. .------. | .------.
| fb2 |-------->| ovl2 |-----' | TV |
'-----' '------' '------'
Video on fb1, shown on LCD and TV
.-----. .------. .------.
| fb0 |-------->| ovl0 |-----.---->| LCD |
'-----' '------' | '------'
.-----. .------. |
| fb1 |----.--->| ovl1 |-----'
'-----' | '------'
.-----. | .------. .------.
| fb2 | '--->| ovl2 |---------->| TV |
'-----' '------' '------'
And how the actual image is composited on the display, we have first the
fb side (no news there):
.---------------------fb-vxres---------------------.
| |
| |
| (xoffset,yoffset) |
| .-------fb-xres------------. |
f | | |
b f | |
| b | |
v | | |
y y | |
r r | |
e e | |
s s | |
| | | |
| '--------------------------' |
| |
| |
'--------------------------------------------------'
The area marked by x/yoffset and x/yres is used as the pixel source for
the overlay.
On the display we have something like this:
.----------------disp-xres----------------.
| |
| (xpos,ypos) |
| .-----ovl-xres-----. |
d | | |
i o | |
s v | |
p l | |
| | | |
y y | |
r r | |
e e | |
s s | |
| | | |
| '------------------' |
| |
'-----------------------------------------'
The x/ypos of the overlay does not have any relation to the x/yoffset of
the framebuffer. The overlay's x/yres is the same as the fb's x/yres in
case the overlay doesn't support scaling (OMAP's case this is true for
overlay0). Otherwise the overlay's x/yres is only limited by the HW's
scaling capabilities.
The overlays have a priority order, and where there's no overlay, a
background color is used. So like this:
.-----------------------------------------.
| background color |
| .-----------------------. |
| | ovl0 | |
| | | |
| | .--------------. | |
| | | ovl1 | | |
| | | | | |
| | | .-------------------. |
| | | | ovl2 | |
| | '--------| | |
| '----------| | |
| | | |
| | | |
| | | |
| '-------------------' |
'-----------------------------------------'
As you may have noticed, this raises in annoying problem: the
framebuffer does not represent the display, and thus the display related
information in the fb, like video timings, are difficult or impossible
to use. I haven't found any solution to this.
> So in addition to your proposed positioning I think we should also have the
> following to give userspace a useful set of functionality:
>
> - a way to discover how the screen is composited (how many windows are there,
> how they are stacked and how to access those)
>
> - a way to enable/disable windows (make them (in)visible)
>
> - reporting and selecting how the window content can be mixed with the root
> screen (overwrite, source or destination color keying)
Right, and there may not be a root screen at all, like on OMAP. (if the
background color doesn't count as a root screen).
> - things like window size and color format could be handled by the usual fb API
> used on the window. However there might be restrictions which cause them to be
> not 100% API compatible (for example when changing the color format if the
> windows are required to have the same format as the root screen)
>
> - do we need to worry about hardware (up/down) scaling of the window content?
>
>
> So is that what you need for a standardized window implementation?
> Any additional things that were useful/needed in this context?
> Would you consider adding support for this API in your drivers? (as
> standardizing wouldn't be useful if nobody would implement it)
We already have the current implementation in omapfb, so while a
standard API would be nice, we still need to keep the old custom API for
compatibility.
Another thing is that I'm not sure how much features we should try to
add to fbdev. The fbdev model is a bit limited (for example, the timings
problem above, or double/triple buffering), and at least we are
currently looking at using DRM. There will still be a framebuffer, but
that's mostly for fbconsole and such, and doesn't need to support
overlays, scaling, and other more complex features.
Tomi
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
2011-09-01 16:45 ` Florian Tobias Schandinat
(?)
@ 2011-09-06 14:16 ` Ajay kumar
-1 siblings, 0 replies; 35+ messages in thread
From: Ajay kumar @ 2011-09-06 14:16 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: Ajay Kumar, linux-samsung-soc, linux-fbdev, linux-arm-kernel,
lethal, jg1.han, m.szyprowski, ben-linux, banajit.g, Manuel Lauss,
Tomi Valkeinen
Hi Florian,
On Thu, Sep 1, 2011 at 10:15 PM, Florian Tobias Schandinat
<FlorianSchandinat@gmx.de> wrote:
> Hi all,
>
> On 08/25/2011 07:51 PM, Ajay Kumar wrote:
>> Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP
>> seem to be doing window/plane positioning in their driver code.
>> Is it possible to have this window positioning support at a common place?
>
> Good point. Congratulations for figuring out that I like to standardize things.
> But I think your suggestion is far from being enough to be useful for userspace
> (which is our goal so that applications can be reused along drivers and don't
> need to know about individual drivers).
Thanks for considering the scenerio. Yes, you are right and we need to
start somewhere.
> So let me at first summarize how I understand you implemented those things after
> having a brief look at some of the drivers:
> Windows are rectangular screen areas whose pixel data come from other locations.
> The other locations are accessible via other framebuffer devices (e.g. fb1). So
> in this area the data of fb1 is shown and not the data of fb0 that would be
> normally shown.
Yes, thats right! The area not covered by the other framebuffer
device/window (e.g. fb1) will be transparent and the framebuffer
device/window below (e.g. fb0) will be visible.
> So in addition to your proposed positioning I think we should also have the
> following to give userspace a useful set of functionality:
>
> - a way to discover how the screen is composited (how many windows are there,
> how they are stacked and how to access those)
This will need more discussions, as the amount of information to be
exposed to the user-space might vary from controller-to-controller.
> - a way to enable/disable windows (make them (in)visible)
This is already present. Switching on/off any particular framebuffer
device/window can be done by calling ioctl with FBIOBLANK, from user
space.
> - reporting and selecting how the window content can be mixed with the root
> screen (overwrite, source or destination color keying)
Yes, thats a good point. This can be achieved by implementing ioctl call
> - things like window size and color format could be handled by the usual fb API
> used on the window. However there might be restrictions which cause them to be
> not 100% API compatible (for example when changing the color format if the
> windows are required to have the same format as the root screen)
This seems to be more to do with the property of the FB controller.
Moreover, the driver can always enforce checks on such hardware
restrictions.
> - do we need to worry about hardware (up/down) scaling of the window content?
The user application should take care of these functions, as this is
directly related to the window size. (Usually these operations are
handled by some separate hardware modules (post-processors) )
>
> So is that what you need for a standardized window implementation?
> Any additional things that were useful/needed in this context?
> Would you consider adding support for this API in your drivers? (as
> standardizing wouldn't be useful if nobody would implement it)
Yes, having these missing features will definitely give the user much
more control over the various available framebuffer devices/windows.
We would like to start with the fb window re-positioning feature and
add more features in coming days.
>
> Best regards,
>
> Florian Tobias Schandinat
>
Thanks for your review and suggestions. It was very helpful.
Best Regards,
Ajay Kumar
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
@ 2011-09-06 14:16 ` Ajay kumar
0 siblings, 0 replies; 35+ messages in thread
From: Ajay kumar @ 2011-09-06 14:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi Florian,
On Thu, Sep 1, 2011 at 10:15 PM, Florian Tobias Schandinat
<FlorianSchandinat@gmx.de> wrote:
> Hi all,
>
> On 08/25/2011 07:51 PM, Ajay Kumar wrote:
>> Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP
>> seem to be doing window/plane positioning in their driver code.
>> Is it possible to have this window positioning support at a common place?
>
> Good point. Congratulations for figuring out that I like to standardize things.
> But I think your suggestion is far from being enough to be useful for userspace
> (which is our goal so that applications can be reused along drivers and don't
> need to know about individual drivers).
Thanks for considering the scenerio. Yes, you are right and we need to
start somewhere.
> So let me at first summarize how I understand you implemented those things after
> having a brief look at some of the drivers:
> Windows are rectangular screen areas whose pixel data come from other locations.
> The other locations are accessible via other framebuffer devices (e.g. fb1). So
> in this area the data of fb1 is shown and not the data of fb0 that would be
> normally shown.
Yes, thats right! The area not covered by the other framebuffer
device/window (e.g. fb1) will be transparent and the framebuffer
device/window below (e.g. fb0) will be visible.
> So in addition to your proposed positioning I think we should also have the
> following to give userspace a useful set of functionality:
>
> - a way to discover how the screen is composited (how many windows are there,
> how they are stacked and how to access those)
This will need more discussions, as the amount of information to be
exposed to the user-space might vary from controller-to-controller.
> - a way to enable/disable windows (make them (in)visible)
This is already present. Switching on/off any particular framebuffer
device/window can be done by calling ioctl with FBIOBLANK, from user
space.
> - reporting and selecting how the window content can be mixed with the root
> screen (overwrite, source or destination color keying)
Yes, thats a good point. This can be achieved by implementing ioctl call
> - things like window size and color format could be handled by the usual fb API
> used on the window. However there might be restrictions which cause them to be
> not 100% API compatible (for example when changing the color format if the
> windows are required to have the same format as the root screen)
This seems to be more to do with the property of the FB controller.
Moreover, the driver can always enforce checks on such hardware
restrictions.
> - do we need to worry about hardware (up/down) scaling of the window content?
The user application should take care of these functions, as this is
directly related to the window size. (Usually these operations are
handled by some separate hardware modules (post-processors) )
>
> So is that what you need for a standardized window implementation?
> Any additional things that were useful/needed in this context?
> Would you consider adding support for this API in your drivers? (as
> standardizing wouldn't be useful if nobody would implement it)
Yes, having these missing features will definitely give the user much
more control over the various available framebuffer devices/windows.
We would like to start with the fb window re-positioning feature and
add more features in coming days.
>
> Best regards,
>
> Florian Tobias Schandinat
>
Thanks for your review and suggestions. It was very helpful.
Best Regards,
Ajay Kumar
^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH 0/2] video: s3c-fb: Add window positioning support
@ 2011-09-06 14:16 ` Ajay kumar
0 siblings, 0 replies; 35+ messages in thread
From: Ajay kumar @ 2011-09-06 14:16 UTC (permalink / raw)
To: linux-arm-kernel
Hi Florian,
On Thu, Sep 1, 2011 at 10:15 PM, Florian Tobias Schandinat
<FlorianSchandinat@gmx.de> wrote:
> Hi all,
>
> On 08/25/2011 07:51 PM, Ajay Kumar wrote:
>> Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP
>> seem to be doing window/plane positioning in their driver code.
>> Is it possible to have this window positioning support at a common place?
>
> Good point. Congratulations for figuring out that I like to standardize things.
> But I think your suggestion is far from being enough to be useful for userspace
> (which is our goal so that applications can be reused along drivers and don't
> need to know about individual drivers).
Thanks for considering the scenerio. Yes, you are right and we need to
start somewhere.
> So let me at first summarize how I understand you implemented those things after
> having a brief look at some of the drivers:
> Windows are rectangular screen areas whose pixel data come from other locations.
> The other locations are accessible via other framebuffer devices (e.g. fb1). So
> in this area the data of fb1 is shown and not the data of fb0 that would be
> normally shown.
Yes, thats right! The area not covered by the other framebuffer
device/window (e.g. fb1) will be transparent and the framebuffer
device/window below (e.g. fb0) will be visible.
> So in addition to your proposed positioning I think we should also have the
> following to give userspace a useful set of functionality:
>
> - a way to discover how the screen is composited (how many windows are there,
> how they are stacked and how to access those)
This will need more discussions, as the amount of information to be
exposed to the user-space might vary from controller-to-controller.
> - a way to enable/disable windows (make them (in)visible)
This is already present. Switching on/off any particular framebuffer
device/window can be done by calling ioctl with FBIOBLANK, from user
space.
> - reporting and selecting how the window content can be mixed with the root
> screen (overwrite, source or destination color keying)
Yes, thats a good point. This can be achieved by implementing ioctl call
> - things like window size and color format could be handled by the usual fb API
> used on the window. However there might be restrictions which cause them to be
> not 100% API compatible (for example when changing the color format if the
> windows are required to have the same format as the root screen)
This seems to be more to do with the property of the FB controller.
Moreover, the driver can always enforce checks on such hardware
restrictions.
> - do we need to worry about hardware (up/down) scaling of the window content?
The user application should take care of these functions, as this is
directly related to the window size. (Usually these operations are
handled by some separate hardware modules (post-processors) )
>
> So is that what you need for a standardized window implementation?
> Any additional things that were useful/needed in this context?
> Would you consider adding support for this API in your drivers? (as
> standardizing wouldn't be useful if nobody would implement it)
Yes, having these missing features will definitely give the user much
more control over the various available framebuffer devices/windows.
We would like to start with the fb window re-positioning feature and
add more features in coming days.
>
> Best regards,
>
> Florian Tobias Schandinat
>
Thanks for your review and suggestions. It was very helpful.
Best Regards,
Ajay Kumar
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
2011-09-01 16:45 ` Florian Tobias Schandinat
(?)
(?)
@ 2011-09-07 15:31 ` Laurent Pinchart
-1 siblings, 0 replies; 35+ messages in thread
From: Laurent Pinchart @ 2011-09-07 15:31 UTC (permalink / raw)
To: linux-arm-kernel
Hi Florian,
On Thursday 01 September 2011 18:45:18 Florian Tobias Schandinat wrote:
> Hi all,
>
> On 08/25/2011 07:51 PM, Ajay Kumar wrote:
> > Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP
> > seem to be doing window/plane positioning in their driver code.
> > Is it possible to have this window positioning support at a common place?
>
> Good point. Congratulations for figuring out that I like to standardize
> things. But I think your suggestion is far from being enough to be useful
> for userspace (which is our goal so that applications can be reused along
> drivers and don't need to know about individual drivers).
Beside standardizing things, do you also like to take them one level higher to
solve challenging issues ? I know the answer must be yes :-)
The problem at hand here is something we have solved in V4L2 (theoretically
only for part of it) with the media controller API, the V4L2 subdevs and their
pad-level format API.
In a nutshell, the media controller lets drivers model hardware as a graph of
buliding blocks connected through their pads and expose that description to
userspace applications. In V4L2 most of those blocks are V4L2 subdevs, which
are abstract building blocks that implement sets of standard operations. Those
operations are exposed to userspace through the V4L2 subdevs pad-level format
API, allowing application to configure sizes and selection rectangles at all
pads in the graph. Selection rectangles can be used to configure cropping and
composing, which is exactly what the window positioning API needs to do.
Instead of creating a new fbdev-specific API to do the same, shouldn't we try
to join forces ?
> So let me at first summarize how I understand you implemented those things
> after having a brief look at some of the drivers:
> Windows are rectangular screen areas whose pixel data come from other
> locations. The other locations are accessible via other framebuffer
> devices (e.g. fb1). So in this area the data of fb1 is shown and not the
> data of fb0 that would be normally shown.
>
> So in addition to your proposed positioning I think we should also have the
> following to give userspace a useful set of functionality:
>
> - a way to discover how the screen is composited (how many windows are
> there, how they are stacked and how to access those)
>
> - a way to enable/disable windows (make them (in)visible)
>
> - reporting and selecting how the window content can be mixed with the root
> screen (overwrite, source or destination color keying)
>
> - things like window size and color format could be handled by the usual fb
> API used on the window. However there might be restrictions which cause
> them to be not 100% API compatible (for example when changing the color
> format if the windows are required to have the same format as the root
> screen)
>
> - do we need to worry about hardware (up/down) scaling of the window
> content?
>
>
> So is that what you need for a standardized window implementation?
> Any additional things that were useful/needed in this context?
> Would you consider adding support for this API in your drivers? (as
> standardizing wouldn't be useful if nobody would implement it)
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
@ 2011-09-07 15:31 ` Laurent Pinchart
0 siblings, 0 replies; 35+ messages in thread
From: Laurent Pinchart @ 2011-09-07 15:31 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: Ajay Kumar, linux-samsung-soc, linux-fbdev, linux-arm-kernel,
lethal, jg1.han, m.szyprowski, ben-linux, banajit.g, Manuel Lauss,
Tomi Valkeinen, Sakari Ailus, linux-media@vger.kernel.org
Hi Florian,
On Thursday 01 September 2011 18:45:18 Florian Tobias Schandinat wrote:
> Hi all,
>
> On 08/25/2011 07:51 PM, Ajay Kumar wrote:
> > Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP
> > seem to be doing window/plane positioning in their driver code.
> > Is it possible to have this window positioning support at a common place?
>
> Good point. Congratulations for figuring out that I like to standardize
> things. But I think your suggestion is far from being enough to be useful
> for userspace (which is our goal so that applications can be reused along
> drivers and don't need to know about individual drivers).
Beside standardizing things, do you also like to take them one level higher to
solve challenging issues ? I know the answer must be yes :-)
The problem at hand here is something we have solved in V4L2 (theoretically
only for part of it) with the media controller API, the V4L2 subdevs and their
pad-level format API.
In a nutshell, the media controller lets drivers model hardware as a graph of
buliding blocks connected through their pads and expose that description to
userspace applications. In V4L2 most of those blocks are V4L2 subdevs, which
are abstract building blocks that implement sets of standard operations. Those
operations are exposed to userspace through the V4L2 subdevs pad-level format
API, allowing application to configure sizes and selection rectangles at all
pads in the graph. Selection rectangles can be used to configure cropping and
composing, which is exactly what the window positioning API needs to do.
Instead of creating a new fbdev-specific API to do the same, shouldn't we try
to join forces ?
> So let me at first summarize how I understand you implemented those things
> after having a brief look at some of the drivers:
> Windows are rectangular screen areas whose pixel data come from other
> locations. The other locations are accessible via other framebuffer
> devices (e.g. fb1). So in this area the data of fb1 is shown and not the
> data of fb0 that would be normally shown.
>
> So in addition to your proposed positioning I think we should also have the
> following to give userspace a useful set of functionality:
>
> - a way to discover how the screen is composited (how many windows are
> there, how they are stacked and how to access those)
>
> - a way to enable/disable windows (make them (in)visible)
>
> - reporting and selecting how the window content can be mixed with the root
> screen (overwrite, source or destination color keying)
>
> - things like window size and color format could be handled by the usual fb
> API used on the window. However there might be restrictions which cause
> them to be not 100% API compatible (for example when changing the color
> format if the windows are required to have the same format as the root
> screen)
>
> - do we need to worry about hardware (up/down) scaling of the window
> content?
>
>
> So is that what you need for a standardized window implementation?
> Any additional things that were useful/needed in this context?
> Would you consider adding support for this API in your drivers? (as
> standardizing wouldn't be useful if nobody would implement it)
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH 0/2] video: s3c-fb: Add window positioning support
@ 2011-09-07 15:31 ` Laurent Pinchart
0 siblings, 0 replies; 35+ messages in thread
From: Laurent Pinchart @ 2011-09-07 15:31 UTC (permalink / raw)
To: linux-arm-kernel
Hi Florian,
On Thursday 01 September 2011 18:45:18 Florian Tobias Schandinat wrote:
> Hi all,
>
> On 08/25/2011 07:51 PM, Ajay Kumar wrote:
> > Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP
> > seem to be doing window/plane positioning in their driver code.
> > Is it possible to have this window positioning support at a common place?
>
> Good point. Congratulations for figuring out that I like to standardize
> things. But I think your suggestion is far from being enough to be useful
> for userspace (which is our goal so that applications can be reused along
> drivers and don't need to know about individual drivers).
Beside standardizing things, do you also like to take them one level higher to
solve challenging issues ? I know the answer must be yes :-)
The problem at hand here is something we have solved in V4L2 (theoretically
only for part of it) with the media controller API, the V4L2 subdevs and their
pad-level format API.
In a nutshell, the media controller lets drivers model hardware as a graph of
buliding blocks connected through their pads and expose that description to
userspace applications. In V4L2 most of those blocks are V4L2 subdevs, which
are abstract building blocks that implement sets of standard operations. Those
operations are exposed to userspace through the V4L2 subdevs pad-level format
API, allowing application to configure sizes and selection rectangles at all
pads in the graph. Selection rectangles can be used to configure cropping and
composing, which is exactly what the window positioning API needs to do.
Instead of creating a new fbdev-specific API to do the same, shouldn't we try
to join forces ?
> So let me at first summarize how I understand you implemented those things
> after having a brief look at some of the drivers:
> Windows are rectangular screen areas whose pixel data come from other
> locations. The other locations are accessible via other framebuffer
> devices (e.g. fb1). So in this area the data of fb1 is shown and not the
> data of fb0 that would be normally shown.
>
> So in addition to your proposed positioning I think we should also have the
> following to give userspace a useful set of functionality:
>
> - a way to discover how the screen is composited (how many windows are
> there, how they are stacked and how to access those)
>
> - a way to enable/disable windows (make them (in)visible)
>
> - reporting and selecting how the window content can be mixed with the root
> screen (overwrite, source or destination color keying)
>
> - things like window size and color format could be handled by the usual fb
> API used on the window. However there might be restrictions which cause
> them to be not 100% API compatible (for example when changing the color
> format if the windows are required to have the same format as the root
> screen)
>
> - do we need to worry about hardware (up/down) scaling of the window
> content?
>
>
> So is that what you need for a standardized window implementation?
> Any additional things that were useful/needed in this context?
> Would you consider adding support for this API in your drivers? (as
> standardizing wouldn't be useful if nobody would implement it)
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
@ 2011-09-07 15:31 ` Laurent Pinchart
0 siblings, 0 replies; 35+ messages in thread
From: Laurent Pinchart @ 2011-09-07 15:31 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: linux-fbdev, linux-samsung-soc, banajit.g, Tomi Valkeinen,
jg1.han, Manuel Lauss, lethal, ben-linux, Sakari Ailus,
linux-media@vger.kernel.org, Ajay Kumar, linux-arm-kernel,
m.szyprowski
Hi Florian,
On Thursday 01 September 2011 18:45:18 Florian Tobias Schandinat wrote:
> Hi all,
>
> On 08/25/2011 07:51 PM, Ajay Kumar wrote:
> > Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP
> > seem to be doing window/plane positioning in their driver code.
> > Is it possible to have this window positioning support at a common place?
>
> Good point. Congratulations for figuring out that I like to standardize
> things. But I think your suggestion is far from being enough to be useful
> for userspace (which is our goal so that applications can be reused along
> drivers and don't need to know about individual drivers).
Beside standardizing things, do you also like to take them one level higher to
solve challenging issues ? I know the answer must be yes :-)
The problem at hand here is something we have solved in V4L2 (theoretically
only for part of it) with the media controller API, the V4L2 subdevs and their
pad-level format API.
In a nutshell, the media controller lets drivers model hardware as a graph of
buliding blocks connected through their pads and expose that description to
userspace applications. In V4L2 most of those blocks are V4L2 subdevs, which
are abstract building blocks that implement sets of standard operations. Those
operations are exposed to userspace through the V4L2 subdevs pad-level format
API, allowing application to configure sizes and selection rectangles at all
pads in the graph. Selection rectangles can be used to configure cropping and
composing, which is exactly what the window positioning API needs to do.
Instead of creating a new fbdev-specific API to do the same, shouldn't we try
to join forces ?
> So let me at first summarize how I understand you implemented those things
> after having a brief look at some of the drivers:
> Windows are rectangular screen areas whose pixel data come from other
> locations. The other locations are accessible via other framebuffer
> devices (e.g. fb1). So in this area the data of fb1 is shown and not the
> data of fb0 that would be normally shown.
>
> So in addition to your proposed positioning I think we should also have the
> following to give userspace a useful set of functionality:
>
> - a way to discover how the screen is composited (how many windows are
> there, how they are stacked and how to access those)
>
> - a way to enable/disable windows (make them (in)visible)
>
> - reporting and selecting how the window content can be mixed with the root
> screen (overwrite, source or destination color keying)
>
> - things like window size and color format could be handled by the usual fb
> API used on the window. However there might be restrictions which cause
> them to be not 100% API compatible (for example when changing the color
> format if the windows are required to have the same format as the root
> screen)
>
> - do we need to worry about hardware (up/down) scaling of the window
> content?
>
>
> So is that what you need for a standardized window implementation?
> Any additional things that were useful/needed in this context?
> Would you consider adding support for this API in your drivers? (as
> standardizing wouldn't be useful if nobody would implement it)
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
2011-09-07 15:31 ` Laurent Pinchart
(?)
@ 2011-09-18 19:29 ` Florian Tobias Schandinat
-1 siblings, 0 replies; 35+ messages in thread
From: Florian Tobias Schandinat @ 2011-09-18 19:29 UTC (permalink / raw)
To: linux-arm-kernel
Hi Laurent,
On 09/07/2011 03:31 PM, Laurent Pinchart wrote:
> Hi Florian,
>
> On Thursday 01 September 2011 18:45:18 Florian Tobias Schandinat wrote:
>> Hi all,
>>
>> On 08/25/2011 07:51 PM, Ajay Kumar wrote:
>>> Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP
>>> seem to be doing window/plane positioning in their driver code.
>>> Is it possible to have this window positioning support at a common place?
>>
>> Good point. Congratulations for figuring out that I like to standardize
>> things. But I think your suggestion is far from being enough to be useful
>> for userspace (which is our goal so that applications can be reused along
>> drivers and don't need to know about individual drivers).
>
> Beside standardizing things, do you also like to take them one level higher to
> solve challenging issues ? I know the answer must be yes :-)
>
> The problem at hand here is something we have solved in V4L2 (theoretically
> only for part of it) with the media controller API, the V4L2 subdevs and their
> pad-level format API.
>
> In a nutshell, the media controller lets drivers model hardware as a graph of
> buliding blocks connected through their pads and expose that description to
> userspace applications. In V4L2 most of those blocks are V4L2 subdevs, which
> are abstract building blocks that implement sets of standard operations. Those
> operations are exposed to userspace through the V4L2 subdevs pad-level format
> API, allowing application to configure sizes and selection rectangles at all
> pads in the graph. Selection rectangles can be used to configure cropping and
> composing, which is exactly what the window positioning API needs to do.
>
> Instead of creating a new fbdev-specific API to do the same, shouldn't we try
> to join forces ?
Okay, thanks for the pointer. After having a look at your API I understand that
it would solve the problem to discover how many windows (in this case) are there
and how they can be accessed. It looks fine for this purpose, powerful enough
and not too complex. So if I get it correct we still need at least a way to
configure the position of the windows/overlays/sink pads similar to what Ajay
proposed. Additionally a way to get and/or set the z-position of the overlays if
multiple overlays overlap and set/get how the overlays work (overdraw, constant
alpha, source/destination color keying). Normally I'd consider these link
properties but I think implementing them as properties of the source framebuffer
or sink pad would work as well.
Is this correct or did I miss something?
Best regards,
Florian Tobias Schandinat
^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH 0/2] video: s3c-fb: Add window positioning support
@ 2011-09-18 19:29 ` Florian Tobias Schandinat
0 siblings, 0 replies; 35+ messages in thread
From: Florian Tobias Schandinat @ 2011-09-18 19:29 UTC (permalink / raw)
To: linux-arm-kernel
Hi Laurent,
On 09/07/2011 03:31 PM, Laurent Pinchart wrote:
> Hi Florian,
>
> On Thursday 01 September 2011 18:45:18 Florian Tobias Schandinat wrote:
>> Hi all,
>>
>> On 08/25/2011 07:51 PM, Ajay Kumar wrote:
>>> Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP
>>> seem to be doing window/plane positioning in their driver code.
>>> Is it possible to have this window positioning support at a common place?
>>
>> Good point. Congratulations for figuring out that I like to standardize
>> things. But I think your suggestion is far from being enough to be useful
>> for userspace (which is our goal so that applications can be reused along
>> drivers and don't need to know about individual drivers).
>
> Beside standardizing things, do you also like to take them one level higher to
> solve challenging issues ? I know the answer must be yes :-)
>
> The problem at hand here is something we have solved in V4L2 (theoretically
> only for part of it) with the media controller API, the V4L2 subdevs and their
> pad-level format API.
>
> In a nutshell, the media controller lets drivers model hardware as a graph of
> buliding blocks connected through their pads and expose that description to
> userspace applications. In V4L2 most of those blocks are V4L2 subdevs, which
> are abstract building blocks that implement sets of standard operations. Those
> operations are exposed to userspace through the V4L2 subdevs pad-level format
> API, allowing application to configure sizes and selection rectangles at all
> pads in the graph. Selection rectangles can be used to configure cropping and
> composing, which is exactly what the window positioning API needs to do.
>
> Instead of creating a new fbdev-specific API to do the same, shouldn't we try
> to join forces ?
Okay, thanks for the pointer. After having a look at your API I understand that
it would solve the problem to discover how many windows (in this case) are there
and how they can be accessed. It looks fine for this purpose, powerful enough
and not too complex. So if I get it correct we still need at least a way to
configure the position of the windows/overlays/sink pads similar to what Ajay
proposed. Additionally a way to get and/or set the z-position of the overlays if
multiple overlays overlap and set/get how the overlays work (overdraw, constant
alpha, source/destination color keying). Normally I'd consider these link
properties but I think implementing them as properties of the source framebuffer
or sink pad would work as well.
Is this correct or did I miss something?
Best regards,
Florian Tobias Schandinat
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
@ 2011-09-18 19:29 ` Florian Tobias Schandinat
0 siblings, 0 replies; 35+ messages in thread
From: Florian Tobias Schandinat @ 2011-09-18 19:29 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Ajay Kumar, linux-samsung-soc, linux-fbdev, linux-arm-kernel,
lethal, jg1.han, m.szyprowski, ben-linux, banajit.g, Manuel Lauss,
Tomi Valkeinen, Sakari Ailus, linux-media@vger.kernel.org
Hi Laurent,
On 09/07/2011 03:31 PM, Laurent Pinchart wrote:
> Hi Florian,
>
> On Thursday 01 September 2011 18:45:18 Florian Tobias Schandinat wrote:
>> Hi all,
>>
>> On 08/25/2011 07:51 PM, Ajay Kumar wrote:
>>> Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP
>>> seem to be doing window/plane positioning in their driver code.
>>> Is it possible to have this window positioning support at a common place?
>>
>> Good point. Congratulations for figuring out that I like to standardize
>> things. But I think your suggestion is far from being enough to be useful
>> for userspace (which is our goal so that applications can be reused along
>> drivers and don't need to know about individual drivers).
>
> Beside standardizing things, do you also like to take them one level higher to
> solve challenging issues ? I know the answer must be yes :-)
>
> The problem at hand here is something we have solved in V4L2 (theoretically
> only for part of it) with the media controller API, the V4L2 subdevs and their
> pad-level format API.
>
> In a nutshell, the media controller lets drivers model hardware as a graph of
> buliding blocks connected through their pads and expose that description to
> userspace applications. In V4L2 most of those blocks are V4L2 subdevs, which
> are abstract building blocks that implement sets of standard operations. Those
> operations are exposed to userspace through the V4L2 subdevs pad-level format
> API, allowing application to configure sizes and selection rectangles at all
> pads in the graph. Selection rectangles can be used to configure cropping and
> composing, which is exactly what the window positioning API needs to do.
>
> Instead of creating a new fbdev-specific API to do the same, shouldn't we try
> to join forces ?
Okay, thanks for the pointer. After having a look at your API I understand that
it would solve the problem to discover how many windows (in this case) are there
and how they can be accessed. It looks fine for this purpose, powerful enough
and not too complex. So if I get it correct we still need at least a way to
configure the position of the windows/overlays/sink pads similar to what Ajay
proposed. Additionally a way to get and/or set the z-position of the overlays if
multiple overlays overlap and set/get how the overlays work (overdraw, constant
alpha, source/destination color keying). Normally I'd consider these link
properties but I think implementing them as properties of the source framebuffer
or sink pad would work as well.
Is this correct or did I miss something?
Best regards,
Florian Tobias Schandinat
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
2011-09-18 19:29 ` Florian Tobias Schandinat
(?)
@ 2011-09-18 20:39 ` Laurent Pinchart
-1 siblings, 0 replies; 35+ messages in thread
From: Laurent Pinchart @ 2011-09-18 20:39 UTC (permalink / raw)
To: linux-arm-kernel
Hi Florian,
On Sunday 18 September 2011 21:29:57 Florian Tobias Schandinat wrote:
> On 09/07/2011 03:31 PM, Laurent Pinchart wrote:
> > On Thursday 01 September 2011 18:45:18 Florian Tobias Schandinat wrote:
> >> On 08/25/2011 07:51 PM, Ajay Kumar wrote:
> >>> Just as a note, there are many drivers like mx3fb.c, au1200fb.c and
> >>> OMAP seem to be doing window/plane positioning in their driver code.
> >>> Is it possible to have this window positioning support at a common
> >>> place?
> >>
> >> Good point. Congratulations for figuring out that I like to standardize
> >> things. But I think your suggestion is far from being enough to be
> >> useful for userspace (which is our goal so that applications can be
> >> reused along drivers and don't need to know about individual drivers).
> >
> > Beside standardizing things, do you also like to take them one level
> > higher to solve challenging issues ? I know the answer must be yes :-)
> >
> > The problem at hand here is something we have solved in V4L2
> > (theoretically only for part of it) with the media controller API, the
> > V4L2 subdevs and their pad-level format API.
> >
> > In a nutshell, the media controller lets drivers model hardware as a
> > graph of buliding blocks connected through their pads and expose that
> > description to userspace applications. In V4L2 most of those blocks are
> > V4L2 subdevs, which are abstract building blocks that implement sets of
> > standard operations. Those operations are exposed to userspace through
> > the V4L2 subdevs pad-level format API, allowing application to configure
> > sizes and selection rectangles at all pads in the graph. Selection
> > rectangles can be used to configure cropping and composing, which is
> > exactly what the window positioning API needs to do.
> >
> > Instead of creating a new fbdev-specific API to do the same, shouldn't we
> > try to join forces ?
>
> Okay, thanks for the pointer. After having a look at your API I understand
> that it would solve the problem to discover how many windows (in this
> case) are there and how they can be accessed. It looks fine for this
> purpose, powerful enough and not too complex. So if I get it correct we
> still need at least a way to configure the position of the
> windows/overlays/sink pads similar to what Ajay proposed.
Yes, the media controller API can only expose the topology to userspace, it
can't be used to configure FB-specific parameters on the pipeline.
> Additionally a way to get and/or set the z-position of the overlays if
> multiple overlays overlap and set/get how the overlays work (overdraw,
> constant alpha, source/destination color keying). Normally I'd consider
> these link properties but I think implementing them as properties of the
> source framebuffer or sink pad would work as well.
> Is this correct or did I miss something?
That's correct.
What bothers me is that both V4L2 and DRM/KMS have the exact same needs. I
don't think it makes sense to implement three different solutions to the same
problem in our three video-related APIs. What's your opinion about that ?
I've tried to raise the issue on the dri-devel mailing list ("Proposal for a
low-level Linux display framework"), but there's still a long way to go before
convincing everybody. Feel free to help me :-)
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 35+ messages in thread* [PATCH 0/2] video: s3c-fb: Add window positioning support
@ 2011-09-18 20:39 ` Laurent Pinchart
0 siblings, 0 replies; 35+ messages in thread
From: Laurent Pinchart @ 2011-09-18 20:39 UTC (permalink / raw)
To: linux-arm-kernel
Hi Florian,
On Sunday 18 September 2011 21:29:57 Florian Tobias Schandinat wrote:
> On 09/07/2011 03:31 PM, Laurent Pinchart wrote:
> > On Thursday 01 September 2011 18:45:18 Florian Tobias Schandinat wrote:
> >> On 08/25/2011 07:51 PM, Ajay Kumar wrote:
> >>> Just as a note, there are many drivers like mx3fb.c, au1200fb.c and
> >>> OMAP seem to be doing window/plane positioning in their driver code.
> >>> Is it possible to have this window positioning support at a common
> >>> place?
> >>
> >> Good point. Congratulations for figuring out that I like to standardize
> >> things. But I think your suggestion is far from being enough to be
> >> useful for userspace (which is our goal so that applications can be
> >> reused along drivers and don't need to know about individual drivers).
> >
> > Beside standardizing things, do you also like to take them one level
> > higher to solve challenging issues ? I know the answer must be yes :-)
> >
> > The problem at hand here is something we have solved in V4L2
> > (theoretically only for part of it) with the media controller API, the
> > V4L2 subdevs and their pad-level format API.
> >
> > In a nutshell, the media controller lets drivers model hardware as a
> > graph of buliding blocks connected through their pads and expose that
> > description to userspace applications. In V4L2 most of those blocks are
> > V4L2 subdevs, which are abstract building blocks that implement sets of
> > standard operations. Those operations are exposed to userspace through
> > the V4L2 subdevs pad-level format API, allowing application to configure
> > sizes and selection rectangles at all pads in the graph. Selection
> > rectangles can be used to configure cropping and composing, which is
> > exactly what the window positioning API needs to do.
> >
> > Instead of creating a new fbdev-specific API to do the same, shouldn't we
> > try to join forces ?
>
> Okay, thanks for the pointer. After having a look at your API I understand
> that it would solve the problem to discover how many windows (in this
> case) are there and how they can be accessed. It looks fine for this
> purpose, powerful enough and not too complex. So if I get it correct we
> still need at least a way to configure the position of the
> windows/overlays/sink pads similar to what Ajay proposed.
Yes, the media controller API can only expose the topology to userspace, it
can't be used to configure FB-specific parameters on the pipeline.
> Additionally a way to get and/or set the z-position of the overlays if
> multiple overlays overlap and set/get how the overlays work (overdraw,
> constant alpha, source/destination color keying). Normally I'd consider
> these link properties but I think implementing them as properties of the
> source framebuffer or sink pad would work as well.
> Is this correct or did I miss something?
That's correct.
What bothers me is that both V4L2 and DRM/KMS have the exact same needs. I
don't think it makes sense to implement three different solutions to the same
problem in our three video-related APIs. What's your opinion about that ?
I've tried to raise the issue on the dri-devel mailing list ("Proposal for a
low-level Linux display framework"), but there's still a long way to go before
convincing everybody. Feel free to help me :-)
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
@ 2011-09-18 20:39 ` Laurent Pinchart
0 siblings, 0 replies; 35+ messages in thread
From: Laurent Pinchart @ 2011-09-18 20:39 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: Ajay Kumar, linux-samsung-soc, linux-fbdev, linux-arm-kernel,
lethal, jg1.han, m.szyprowski, ben-linux, banajit.g, Manuel Lauss,
Tomi Valkeinen, Sakari Ailus, linux-media@vger.kernel.org
Hi Florian,
On Sunday 18 September 2011 21:29:57 Florian Tobias Schandinat wrote:
> On 09/07/2011 03:31 PM, Laurent Pinchart wrote:
> > On Thursday 01 September 2011 18:45:18 Florian Tobias Schandinat wrote:
> >> On 08/25/2011 07:51 PM, Ajay Kumar wrote:
> >>> Just as a note, there are many drivers like mx3fb.c, au1200fb.c and
> >>> OMAP seem to be doing window/plane positioning in their driver code.
> >>> Is it possible to have this window positioning support at a common
> >>> place?
> >>
> >> Good point. Congratulations for figuring out that I like to standardize
> >> things. But I think your suggestion is far from being enough to be
> >> useful for userspace (which is our goal so that applications can be
> >> reused along drivers and don't need to know about individual drivers).
> >
> > Beside standardizing things, do you also like to take them one level
> > higher to solve challenging issues ? I know the answer must be yes :-)
> >
> > The problem at hand here is something we have solved in V4L2
> > (theoretically only for part of it) with the media controller API, the
> > V4L2 subdevs and their pad-level format API.
> >
> > In a nutshell, the media controller lets drivers model hardware as a
> > graph of buliding blocks connected through their pads and expose that
> > description to userspace applications. In V4L2 most of those blocks are
> > V4L2 subdevs, which are abstract building blocks that implement sets of
> > standard operations. Those operations are exposed to userspace through
> > the V4L2 subdevs pad-level format API, allowing application to configure
> > sizes and selection rectangles at all pads in the graph. Selection
> > rectangles can be used to configure cropping and composing, which is
> > exactly what the window positioning API needs to do.
> >
> > Instead of creating a new fbdev-specific API to do the same, shouldn't we
> > try to join forces ?
>
> Okay, thanks for the pointer. After having a look at your API I understand
> that it would solve the problem to discover how many windows (in this
> case) are there and how they can be accessed. It looks fine for this
> purpose, powerful enough and not too complex. So if I get it correct we
> still need at least a way to configure the position of the
> windows/overlays/sink pads similar to what Ajay proposed.
Yes, the media controller API can only expose the topology to userspace, it
can't be used to configure FB-specific parameters on the pipeline.
> Additionally a way to get and/or set the z-position of the overlays if
> multiple overlays overlap and set/get how the overlays work (overdraw,
> constant alpha, source/destination color keying). Normally I'd consider
> these link properties but I think implementing them as properties of the
> source framebuffer or sink pad would work as well.
> Is this correct or did I miss something?
That's correct.
What bothers me is that both V4L2 and DRM/KMS have the exact same needs. I
don't think it makes sense to implement three different solutions to the same
problem in our three video-related APIs. What's your opinion about that ?
I've tried to raise the issue on the dri-devel mailing list ("Proposal for a
low-level Linux display framework"), but there's still a long way to go before
convincing everybody. Feel free to help me :-)
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 35+ messages in thread
* RE: [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window positioning
2011-08-25 19:51 ` Ajay Kumar
@ 2011-08-26 0:44 ` JinGoo Han
-1 siblings, 0 replies; 35+ messages in thread
From: JinGoo Han @ 2011-08-26 0:44 UTC (permalink / raw)
To: AJAY KUMAR RAMAKRISHNA SHYMALAMMA,
linux-samsung-soc@vger.kernel.org, linux-fbdev@vger.kernel.org
Cc: FlorianSchandinat@gmx.de, lethal@linux-sh.org, Marek Szyprowski,
ben-linux@fluff.org, BANAJIT GOSWAMI
Hi, Ajay.
> -----Original Message-----
> From: Ajay Kumar [mailto:ajaykumar.rs@samsung.com]
> Sent: Friday, August 26, 2011 4:52 AM
> To: linux-samsung-soc@vger.kernel.org; linux-fbdev@vger.kernel.org; linux-
> arm-kernel@lists.infradead.org
> Cc: FlorianSchandinat@gmx.de; lethal@linux-sh.org; jg1.han@samsung.com;
> m.szyprowski@samsung.com; ben-linux@fluff.org; banajit.g@samsung.com
> Subject: [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window
> positioning
>
> This patch modifies the existing s3c-fb driver to provide
> flexibility to the user to reposition the framebuffer windows.
>
> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
> ---
> drivers/video/s3c-fb.c | 37 ++++++++++++++++++++++++++++++++-----
> 1 files changed, 32 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 0fda252..41179d7 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -442,6 +442,7 @@ static int s3c_fb_set_par(struct fb_info *info)
> struct fb_var_screeninfo *var = &info->var;
> struct s3c_fb_win *win = info->par;
> struct s3c_fb *sfb = win->parent;
> + struct s3cfb_window_pos *winpos = &win->windata->winpos;
> void __iomem *regs = sfb->regs;
> void __iomem *buf = regs;
> int win_no = win->index;
> @@ -539,12 +540,13 @@ static int s3c_fb_set_par(struct fb_info *info)
>
> /* write 'OSD' registers to control position of framebuffer */
>
> - data = VIDOSDxA_TOPLEFT_X(0) | VIDOSDxA_TOPLEFT_Y(0);
> + data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
> + VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
> writel(data, regs + VIDOSD_A(win_no, sfb->variant));
>
> - data = VIDOSDxB_BOTRIGHT_X(s3c_fb_align_word(var->bits_per_pixel,
> - var->xres - 1)) |
> - VIDOSDxB_BOTRIGHT_Y(var->yres - 1);
> + data = VIDOSDxB_BOTRIGHT_X((s3c_fb_align_word(var->bits_per_pixel,
> + (winpos->win_pos_x + var->xres - 1)))) |
> + VIDOSDxB_BOTRIGHT_Y((winpos->win_pos_y + var->yres - 1));
>
> writel(data, regs + VIDOSD_B(win_no, sfb->variant));
>
> @@ -999,8 +1001,10 @@ static int s3c_fb_ioctl(struct fb_info *info,
> unsigned int cmd,
> {
> struct s3c_fb_win *win = info->par;
> struct s3c_fb *sfb = win->parent;
> - int ret;
> + struct s3cfb_window_pos *winpos = &win->windata->winpos;
> + int ret = 0;
> u32 crtc;
> + u32 data;
>
> switch (cmd) {
> case FBIO_WAITFORVSYNC:
> @@ -1011,6 +1015,29 @@ static int s3c_fb_ioctl(struct fb_info *info,
> unsigned int cmd,
>
> ret = s3c_fb_wait_for_vsync(sfb, crtc);
> break;
> + case S3CFB_WIN_POSITION:
> + if (copy_from_user(winpos, (u32 __user *)arg,
> + sizeof(struct s3cfb_window_pos))) {
> + ret = -EFAULT;
> + break;
> + }
> +
> + shadow_protect_win(win, 1);
> +
> + /* write 'OSD' registers to set position of the window */
> + data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
> + VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
> + writel(data, sfb->regs + VIDOSD_A(win->index, sfb->variant));
> +
> + data = VIDOSDxB_BOTRIGHT_X(
> + s3c_fb_align_word(info->var.bits_per_pixel,
> + (winpos->win_pos_x + info->var.xres - 1)));
> + data |= VIDOSDxB_BOTRIGHT_Y(winpos->win_pos_y +
> + info->var.yres - 1);
> + writel(data, sfb->regs + VIDOSD_B(win->index, sfb->variant));
> +
> + shadow_protect_win(win, 0);
> + break;
Can you move this to separate function?
In my opinion, it would be better for readability and consistency.
Also, FBIO_WAITFORVSYNC has been implemented in this way.
ret = s3c_fb_wait_for_vsync(sfb, crtc);
How about adding a function 's3c_fb_set_window_position' for this as belows?
+int s3c_fb_set_window_position(struct fb_info *info,
+ struct s3cfb_window_pos winpos)
........
+ case S3CFB_WIN_POSITION:
+ if (copy_from_user(winpos, (u32 __user *)arg,
+ sizeof(struct s3cfb_window_pos))) {
+ ret = -EFAULT;
+ break;
+ }
+ ret = s3c_fb_set_window_position(info, winpos);
+ break;
> default:
> ret = -ENOTTY;
> }
> --
> 1.7.0.4
^ permalink raw reply [flat|nested] 35+ messages in thread* RE: [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window
@ 2011-08-26 0:44 ` JinGoo Han
0 siblings, 0 replies; 35+ messages in thread
From: JinGoo Han @ 2011-08-26 0:44 UTC (permalink / raw)
To: AJAY KUMAR RAMAKRISHNA SHYMALAMMA,
linux-samsung-soc@vger.kernel.org, linux-fbdev@vger.kernel.org
Cc: FlorianSchandinat@gmx.de, lethal@linux-sh.org, Marek Szyprowski,
ben-linux@fluff.org, BANAJIT GOSWAMI
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 4182 bytes --]
Hi, Ajay.
> -----Original Message-----
> From: Ajay Kumar [mailto:ajaykumar.rs@samsung.com]
> Sent: Friday, August 26, 2011 4:52 AM
> To: linux-samsung-soc@vger.kernel.org; linux-fbdev@vger.kernel.org; linux-
> arm-kernel@lists.infradead.org
> Cc: FlorianSchandinat@gmx.de; lethal@linux-sh.org; jg1.han@samsung.com;
> m.szyprowski@samsung.com; ben-linux@fluff.org; banajit.g@samsung.com
> Subject: [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window
> positioning
>
> This patch modifies the existing s3c-fb driver to provide
> flexibility to the user to reposition the framebuffer windows.
>
> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
> ---
> drivers/video/s3c-fb.c | 37 ++++++++++++++++++++++++++++++++-----
> 1 files changed, 32 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 0fda252..41179d7 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -442,6 +442,7 @@ static int s3c_fb_set_par(struct fb_info *info)
> struct fb_var_screeninfo *var = &info->var;
> struct s3c_fb_win *win = info->par;
> struct s3c_fb *sfb = win->parent;
> + struct s3cfb_window_pos *winpos = &win->windata->winpos;
> void __iomem *regs = sfb->regs;
> void __iomem *buf = regs;
> int win_no = win->index;
> @@ -539,12 +540,13 @@ static int s3c_fb_set_par(struct fb_info *info)
>
> /* write 'OSD' registers to control position of framebuffer */
>
> - data = VIDOSDxA_TOPLEFT_X(0) | VIDOSDxA_TOPLEFT_Y(0);
> + data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
> + VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
> writel(data, regs + VIDOSD_A(win_no, sfb->variant));
>
> - data = VIDOSDxB_BOTRIGHT_X(s3c_fb_align_word(var->bits_per_pixel,
> - var->xres - 1)) |
> - VIDOSDxB_BOTRIGHT_Y(var->yres - 1);
> + data = VIDOSDxB_BOTRIGHT_X((s3c_fb_align_word(var->bits_per_pixel,
> + (winpos->win_pos_x + var->xres - 1)))) |
> + VIDOSDxB_BOTRIGHT_Y((winpos->win_pos_y + var->yres - 1));
>
> writel(data, regs + VIDOSD_B(win_no, sfb->variant));
>
> @@ -999,8 +1001,10 @@ static int s3c_fb_ioctl(struct fb_info *info,
> unsigned int cmd,
> {
> struct s3c_fb_win *win = info->par;
> struct s3c_fb *sfb = win->parent;
> - int ret;
> + struct s3cfb_window_pos *winpos = &win->windata->winpos;
> + int ret = 0;
> u32 crtc;
> + u32 data;
>
> switch (cmd) {
> case FBIO_WAITFORVSYNC:
> @@ -1011,6 +1015,29 @@ static int s3c_fb_ioctl(struct fb_info *info,
> unsigned int cmd,
>
> ret = s3c_fb_wait_for_vsync(sfb, crtc);
> break;
> + case S3CFB_WIN_POSITION:
> + if (copy_from_user(winpos, (u32 __user *)arg,
> + sizeof(struct s3cfb_window_pos))) {
> + ret = -EFAULT;
> + break;
> + }
> +
> + shadow_protect_win(win, 1);
> +
> + /* write 'OSD' registers to set position of the window */
> + data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
> + VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
> + writel(data, sfb->regs + VIDOSD_A(win->index, sfb->variant));
> +
> + data = VIDOSDxB_BOTRIGHT_X(
> + s3c_fb_align_word(info->var.bits_per_pixel,
> + (winpos->win_pos_x + info->var.xres - 1)));
> + data |= VIDOSDxB_BOTRIGHT_Y(winpos->win_pos_y +
> + info->var.yres - 1);
> + writel(data, sfb->regs + VIDOSD_B(win->index, sfb->variant));
> +
> + shadow_protect_win(win, 0);
> + break;
Can you move this to separate function?
In my opinion, it would be better for readability and consistency.
Also, FBIO_WAITFORVSYNC has been implemented in this way.
ret = s3c_fb_wait_for_vsync(sfb, crtc);
How about adding a function 's3c_fb_set_window_position' for this as belows?
+int s3c_fb_set_window_position(struct fb_info *info,
+ struct s3cfb_window_pos winpos)
........
+ case S3CFB_WIN_POSITION:
+ if (copy_from_user(winpos, (u32 __user *)arg,
+ sizeof(struct s3cfb_window_pos))) {
+ ret = -EFAULT;
+ break;
+ }
+ ret = s3c_fb_set_window_position(info, winpos);
+ break;
> default:
> ret = -ENOTTY;
> }
> --
> 1.7.0.4
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ýöÝzÿâžØ^n‡r¡ö¦zË\x1aëh™¨èÚ&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~††Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window positioning
2011-08-26 0:44 ` [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window JinGoo Han
(?)
@ 2011-08-26 5:21 ` Ajay kumar
-1 siblings, 0 replies; 35+ messages in thread
From: Ajay kumar @ 2011-08-26 5:21 UTC (permalink / raw)
To: jg1.han
Cc: AJAY KUMAR RAMAKRISHNA SHYMALAMMA,
linux-samsung-soc@vger.kernel.org, linux-fbdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, FlorianSchandinat@gmx.de,
lethal@linux-sh.org, Marek Szyprowski, ben-linux@fluff.org,
BANAJIT GOSWAMI
Hi Jingoo,
2011/8/26 JinGoo Han <jg1.han@samsung.com>:
> Hi, Ajay.
>> -----Original Message-----
>> From: Ajay Kumar [mailto:ajaykumar.rs@samsung.com]
>> Sent: Friday, August 26, 2011 4:52 AM
>> To: linux-samsung-soc@vger.kernel.org; linux-fbdev@vger.kernel.org; linux-
>> arm-kernel@lists.infradead.org
>> Cc: FlorianSchandinat@gmx.de; lethal@linux-sh.org; jg1.han@samsung.com;
>> m.szyprowski@samsung.com; ben-linux@fluff.org; banajit.g@samsung.com
>> Subject: [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window
>> positioning
>>
>> This patch modifies the existing s3c-fb driver to provide
>> flexibility to the user to reposition the framebuffer windows.
>>
>> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
>> Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
>> ---
>> drivers/video/s3c-fb.c | 37 ++++++++++++++++++++++++++++++++-----
>> 1 files changed, 32 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
>> index 0fda252..41179d7 100644
>> --- a/drivers/video/s3c-fb.c
>> +++ b/drivers/video/s3c-fb.c
>> @@ -442,6 +442,7 @@ static int s3c_fb_set_par(struct fb_info *info)
>> struct fb_var_screeninfo *var = &info->var;
>> struct s3c_fb_win *win = info->par;
>> struct s3c_fb *sfb = win->parent;
>> + struct s3cfb_window_pos *winpos = &win->windata->winpos;
>> void __iomem *regs = sfb->regs;
>> void __iomem *buf = regs;
>> int win_no = win->index;
>> @@ -539,12 +540,13 @@ static int s3c_fb_set_par(struct fb_info *info)
>>
>> /* write 'OSD' registers to control position of framebuffer */
>>
>> - data = VIDOSDxA_TOPLEFT_X(0) | VIDOSDxA_TOPLEFT_Y(0);
>> + data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
>> + VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
>> writel(data, regs + VIDOSD_A(win_no, sfb->variant));
>>
>> - data = VIDOSDxB_BOTRIGHT_X(s3c_fb_align_word(var->bits_per_pixel,
>> - var->xres - 1)) |
>> - VIDOSDxB_BOTRIGHT_Y(var->yres - 1);
>> + data = VIDOSDxB_BOTRIGHT_X((s3c_fb_align_word(var->bits_per_pixel,
>> + (winpos->win_pos_x + var->xres - 1)))) |
>> + VIDOSDxB_BOTRIGHT_Y((winpos->win_pos_y + var->yres - 1));
>>
>> writel(data, regs + VIDOSD_B(win_no, sfb->variant));
>>
>> @@ -999,8 +1001,10 @@ static int s3c_fb_ioctl(struct fb_info *info,
>> unsigned int cmd,
>> {
>> struct s3c_fb_win *win = info->par;
>> struct s3c_fb *sfb = win->parent;
>> - int ret;
>> + struct s3cfb_window_pos *winpos = &win->windata->winpos;
>> + int ret = 0;
>> u32 crtc;
>> + u32 data;
>>
>> switch (cmd) {
>> case FBIO_WAITFORVSYNC:
>> @@ -1011,6 +1015,29 @@ static int s3c_fb_ioctl(struct fb_info *info,
>> unsigned int cmd,
>>
>> ret = s3c_fb_wait_for_vsync(sfb, crtc);
>> break;
>> + case S3CFB_WIN_POSITION:
>> + if (copy_from_user(winpos, (u32 __user *)arg,
>> + sizeof(struct s3cfb_window_pos))) {
>> + ret = -EFAULT;
>> + break;
>> + }
>> +
>> + shadow_protect_win(win, 1);
>> +
>> + /* write 'OSD' registers to set position of the window */
>> + data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
>> + VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
>> + writel(data, sfb->regs + VIDOSD_A(win->index, sfb->variant));
>> +
>> + data = VIDOSDxB_BOTRIGHT_X(
>> + s3c_fb_align_word(info->var.bits_per_pixel,
>> + (winpos->win_pos_x + info->var.xres - 1)));
>> + data |= VIDOSDxB_BOTRIGHT_Y(winpos->win_pos_y +
>> + info->var.yres - 1);
>> + writel(data, sfb->regs + VIDOSD_B(win->index, sfb->variant));
>> +
>> + shadow_protect_win(win, 0);
>> + break;
> Can you move this to separate function?
> In my opinion, it would be better for readability and consistency.
> Also, FBIO_WAITFORVSYNC has been implemented in this way.
> ret = s3c_fb_wait_for_vsync(sfb, crtc);
> How about adding a function 's3c_fb_set_window_position' for this as belows?
> +int s3c_fb_set_window_position(struct fb_info *info,
> + struct s3cfb_window_pos winpos)
Thanks for your suggestion.
I have considered it, and now I have written a separate function for this.
I will be sending it in V2 version.
> ........
> + case S3CFB_WIN_POSITION:
> + if (copy_from_user(winpos, (u32 __user *)arg,
> + sizeof(struct s3cfb_window_pos))) {
> + ret = -EFAULT;
> + break;
> + }
> + ret = s3c_fb_set_window_position(info, winpos);
> + break;
>> default:
>> ret = -ENOTTY;
>> }
>> --
>> 1.7.0.4
>
>
>
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window positioning
@ 2011-08-26 5:21 ` Ajay kumar
0 siblings, 0 replies; 35+ messages in thread
From: Ajay kumar @ 2011-08-26 5:33 UTC (permalink / raw)
To: linux-arm-kernel
Hi Jingoo,
2011/8/26 JinGoo Han <jg1.han@samsung.com>:
> Hi, Ajay.
>> -----Original Message-----
>> From: Ajay Kumar [mailto:ajaykumar.rs@samsung.com]
>> Sent: Friday, August 26, 2011 4:52 AM
>> To: linux-samsung-soc@vger.kernel.org; linux-fbdev@vger.kernel.org; linux-
>> arm-kernel@lists.infradead.org
>> Cc: FlorianSchandinat@gmx.de; lethal@linux-sh.org; jg1.han@samsung.com;
>> m.szyprowski@samsung.com; ben-linux@fluff.org; banajit.g@samsung.com
>> Subject: [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window
>> positioning
>>
>> This patch modifies the existing s3c-fb driver to provide
>> flexibility to the user to reposition the framebuffer windows.
>>
>> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
>> Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
>> ---
>> drivers/video/s3c-fb.c | 37 ++++++++++++++++++++++++++++++++-----
>> 1 files changed, 32 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
>> index 0fda252..41179d7 100644
>> --- a/drivers/video/s3c-fb.c
>> +++ b/drivers/video/s3c-fb.c
>> @@ -442,6 +442,7 @@ static int s3c_fb_set_par(struct fb_info *info)
>> struct fb_var_screeninfo *var = &info->var;
>> struct s3c_fb_win *win = info->par;
>> struct s3c_fb *sfb = win->parent;
>> + struct s3cfb_window_pos *winpos = &win->windata->winpos;
>> void __iomem *regs = sfb->regs;
>> void __iomem *buf = regs;
>> int win_no = win->index;
>> @@ -539,12 +540,13 @@ static int s3c_fb_set_par(struct fb_info *info)
>>
>> /* write 'OSD' registers to control position of framebuffer */
>>
>> - data = VIDOSDxA_TOPLEFT_X(0) | VIDOSDxA_TOPLEFT_Y(0);
>> + data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
>> + VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
>> writel(data, regs + VIDOSD_A(win_no, sfb->variant));
>>
>> - data = VIDOSDxB_BOTRIGHT_X(s3c_fb_align_word(var->bits_per_pixel,
>> - var->xres - 1)) |
>> - VIDOSDxB_BOTRIGHT_Y(var->yres - 1);
>> + data = VIDOSDxB_BOTRIGHT_X((s3c_fb_align_word(var->bits_per_pixel,
>> + (winpos->win_pos_x + var->xres - 1)))) |
>> + VIDOSDxB_BOTRIGHT_Y((winpos->win_pos_y + var->yres - 1));
>>
>> writel(data, regs + VIDOSD_B(win_no, sfb->variant));
>>
>> @@ -999,8 +1001,10 @@ static int s3c_fb_ioctl(struct fb_info *info,
>> unsigned int cmd,
>> {
>> struct s3c_fb_win *win = info->par;
>> struct s3c_fb *sfb = win->parent;
>> - int ret;
>> + struct s3cfb_window_pos *winpos = &win->windata->winpos;
>> + int ret = 0;
>> u32 crtc;
>> + u32 data;
>>
>> switch (cmd) {
>> case FBIO_WAITFORVSYNC:
>> @@ -1011,6 +1015,29 @@ static int s3c_fb_ioctl(struct fb_info *info,
>> unsigned int cmd,
>>
>> ret = s3c_fb_wait_for_vsync(sfb, crtc);
>> break;
>> + case S3CFB_WIN_POSITION:
>> + if (copy_from_user(winpos, (u32 __user *)arg,
>> + sizeof(struct s3cfb_window_pos))) {
>> + ret = -EFAULT;
>> + break;
>> + }
>> +
>> + shadow_protect_win(win, 1);
>> +
>> + /* write 'OSD' registers to set position of the window */
>> + data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
>> + VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
>> + writel(data, sfb->regs + VIDOSD_A(win->index, sfb->variant));
>> +
>> + data = VIDOSDxB_BOTRIGHT_X(
>> + s3c_fb_align_word(info->var.bits_per_pixel,
>> + (winpos->win_pos_x + info->var.xres - 1)));
>> + data |= VIDOSDxB_BOTRIGHT_Y(winpos->win_pos_y +
>> + info->var.yres - 1);
>> + writel(data, sfb->regs + VIDOSD_B(win->index, sfb->variant));
>> +
>> + shadow_protect_win(win, 0);
>> + break;
> Can you move this to separate function?
> In my opinion, it would be better for readability and consistency.
> Also, FBIO_WAITFORVSYNC has been implemented in this way.
> ret = s3c_fb_wait_for_vsync(sfb, crtc);
> How about adding a function 's3c_fb_set_window_position' for this as belows?
> +int s3c_fb_set_window_position(struct fb_info *info,
> + struct s3cfb_window_pos winpos)
Thanks for your suggestion.
I have considered it, and now I have written a separate function for this.
I will be sending it in V2 version.
> ........
> + case S3CFB_WIN_POSITION:
> + if (copy_from_user(winpos, (u32 __user *)arg,
> + sizeof(struct s3cfb_window_pos))) {
> + ret = -EFAULT;
> + break;
> + }
> + ret = s3c_fb_set_window_position(info, winpos);
> + break;
>> default:
>> ret = -ENOTTY;
>> }
>> --
>> 1.7.0.4
>
>
>
^ permalink raw reply [flat|nested] 35+ messages in thread* [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window positioning
@ 2011-08-26 5:21 ` Ajay kumar
0 siblings, 0 replies; 35+ messages in thread
From: Ajay kumar @ 2011-08-26 5:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi Jingoo,
2011/8/26 JinGoo Han <jg1.han@samsung.com>:
> Hi, Ajay.
>> -----Original Message-----
>> From: Ajay Kumar [mailto:ajaykumar.rs at samsung.com]
>> Sent: Friday, August 26, 2011 4:52 AM
>> To: linux-samsung-soc at vger.kernel.org; linux-fbdev at vger.kernel.org; linux-
>> arm-kernel at lists.infradead.org
>> Cc: FlorianSchandinat at gmx.de; lethal at linux-sh.org; jg1.han at samsung.com;
>> m.szyprowski at samsung.com; ben-linux at fluff.org; banajit.g at samsung.com
>> Subject: [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window
>> positioning
>>
>> This patch modifies the existing s3c-fb driver to provide
>> flexibility to the user to reposition the framebuffer windows.
>>
>> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
>> Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
>> ---
>> ?drivers/video/s3c-fb.c | ? 37 ++++++++++++++++++++++++++++++++-----
>> ?1 files changed, 32 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
>> index 0fda252..41179d7 100644
>> --- a/drivers/video/s3c-fb.c
>> +++ b/drivers/video/s3c-fb.c
>> @@ -442,6 +442,7 @@ static int s3c_fb_set_par(struct fb_info *info)
>> ? ? ? struct fb_var_screeninfo *var = &info->var;
>> ? ? ? struct s3c_fb_win *win = info->par;
>> ? ? ? struct s3c_fb *sfb = win->parent;
>> + ? ? struct s3cfb_window_pos *winpos = &win->windata->winpos;
>> ? ? ? void __iomem *regs = sfb->regs;
>> ? ? ? void __iomem *buf = regs;
>> ? ? ? int win_no = win->index;
>> @@ -539,12 +540,13 @@ static int s3c_fb_set_par(struct fb_info *info)
>>
>> ? ? ? /* write 'OSD' registers to control position of framebuffer */
>>
>> - ? ? data = VIDOSDxA_TOPLEFT_X(0) | VIDOSDxA_TOPLEFT_Y(0);
>> + ? ? data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
>> + ? ? ? ? ? ?VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
>> ? ? ? writel(data, regs + VIDOSD_A(win_no, sfb->variant));
>>
>> - ? ? data = VIDOSDxB_BOTRIGHT_X(s3c_fb_align_word(var->bits_per_pixel,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?var->xres - 1)) |
>> - ? ? ? ? ? ?VIDOSDxB_BOTRIGHT_Y(var->yres - 1);
>> + ? ? data = VIDOSDxB_BOTRIGHT_X((s3c_fb_align_word(var->bits_per_pixel,
>> + ? ? ? ? ? ?(winpos->win_pos_x + var->xres - 1)))) |
>> + ? ? ? ? ? ?VIDOSDxB_BOTRIGHT_Y((winpos->win_pos_y + var->yres - 1));
>>
>> ? ? ? writel(data, regs + VIDOSD_B(win_no, sfb->variant));
>>
>> @@ -999,8 +1001,10 @@ static int s3c_fb_ioctl(struct fb_info *info,
>> unsigned int cmd,
>> ?{
>> ? ? ? struct s3c_fb_win *win = info->par;
>> ? ? ? struct s3c_fb *sfb = win->parent;
>> - ? ? int ret;
>> + ? ? struct s3cfb_window_pos *winpos = &win->windata->winpos;
>> + ? ? int ret = 0;
>> ? ? ? u32 crtc;
>> + ? ? u32 data;
>>
>> ? ? ? switch (cmd) {
>> ? ? ? case FBIO_WAITFORVSYNC:
>> @@ -1011,6 +1015,29 @@ static int s3c_fb_ioctl(struct fb_info *info,
>> unsigned int cmd,
>>
>> ? ? ? ? ? ? ? ret = s3c_fb_wait_for_vsync(sfb, crtc);
>> ? ? ? ? ? ? ? break;
>> + ? ? case S3CFB_WIN_POSITION:
>> + ? ? ? ? ? ? if (copy_from_user(winpos, (u32 __user *)arg,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? sizeof(struct s3cfb_window_pos))) {
>> + ? ? ? ? ? ? ? ? ? ? ret = -EFAULT;
>> + ? ? ? ? ? ? ? ? ? ? break;
>> + ? ? ? ? ? ? }
>> +
>> + ? ? ? ? ? ? shadow_protect_win(win, 1);
>> +
>> + ? ? ? ? ? ? /* write 'OSD' registers to set position of the window */
>> + ? ? ? ? ? ? data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
>> + ? ? ? ? ? ? ? ? ? ?VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
>> + ? ? ? ? ? ? writel(data, sfb->regs + VIDOSD_A(win->index, sfb->variant));
>> +
>> + ? ? ? ? ? ? data = VIDOSDxB_BOTRIGHT_X(
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? s3c_fb_align_word(info->var.bits_per_pixel,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? (winpos->win_pos_x + info->var.xres - 1)));
>> + ? ? ? ? ? ? data |= VIDOSDxB_BOTRIGHT_Y(winpos->win_pos_y +
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? info->var.yres - 1);
>> + ? ? ? ? ? ? writel(data, sfb->regs + VIDOSD_B(win->index, sfb->variant));
>> +
>> + ? ? ? ? ? ? shadow_protect_win(win, 0);
>> + ? ? ? ? ? ? break;
> Can you move this to separate function?
> In my opinion, it would be better for readability and consistency.
> Also, FBIO_WAITFORVSYNC has been implemented in this way.
> ? ? ? ? ? ? ? ?ret = s3c_fb_wait_for_vsync(sfb, crtc);
> How about adding a function 's3c_fb_set_window_position' for this as belows?
> +int s3c_fb_set_window_position(struct fb_info *info,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct s3cfb_window_pos winpos)
Thanks for your suggestion.
I have considered it, and now I have written a separate function for this.
I will be sending it in V2 version.
> ? ? ? ? ? ? ? ?........
> + ? ? ? case S3CFB_WIN_POSITION:
> + ? ? ? ? ? ? ? if (copy_from_user(winpos, (u32 __user *)arg,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? sizeof(struct s3cfb_window_pos))) {
> + ? ? ? ? ? ? ? ? ? ? ? ret = -EFAULT;
> + ? ? ? ? ? ? ? ? ? ? ? break;
> + ? ? ? ? ? ? ? }
> + ? ? ? ? ? ? ? ret = s3c_fb_set_window_position(info, winpos);
> + ? ? ? ? ? ? ? break;
>> ? ? ? default:
>> ? ? ? ? ? ? ? ret = -ENOTTY;
>> ? ? ? }
>> --
>> 1.7.0.4
>
>
>
^ permalink raw reply [flat|nested] 35+ messages in thread
* RE: [PATCH 1/2] ARM: SAMSUNG: Add Window Positioning Support for s3c-fb driver
2011-08-25 19:51 ` Ajay Kumar
@ 2011-08-26 5:56 ` Jingoo Han
-1 siblings, 0 replies; 35+ messages in thread
From: Jingoo Han @ 2011-08-26 5:56 UTC (permalink / raw)
To: AJAY KUMAR RAMAKRISHNA SHYMALAMMA
Cc: linux-samsung-soc@vger.kernel.org, linux-fbdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, FlorianSchandinat@gmx.de,
lethal@linux-sh.org, Jingoo Han, Marek Szyprowski,
ben-linux@fluff.org, BANAJIT GOSWAMI
Hi, Ajay.
> -----Original Message-----
> From: Ajay Kumar [mailto:ajaykumar.rs@samsung.com]
> Sent: Friday, August 26, 2011 4:52 AM
> To: linux-samsung-soc@vger.kernel.org; linux-fbdev@vger.kernel.org; linux-
> arm-kernel@lists.infradead.org
> Cc: FlorianSchandinat@gmx.de; lethal@linux-sh.org; jg1.han@samsung.com;
> m.szyprowski@samsung.com; ben-linux@fluff.org; banajit.g@samsung.com
> Subject: [PATCH 1/2] ARM: SAMSUNG: Add Window Positioning Support for s3c-
> fb driver
>
> This patch:
> --adds a data-structure to hold the current position of windows.
> --adds an ioctl number to support dynamic positioning the windows.
>
> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
> ---
> arch/arm/plat-samsung/include/plat/fb.h | 14 ++++++++++++++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-samsung/include/plat/fb.h b/arch/arm/plat-
> samsung/include/plat/fb.h
> index bd79c0a..77ed75c 100644
> --- a/arch/arm/plat-samsung/include/plat/fb.h
> +++ b/arch/arm/plat-samsung/include/plat/fb.h
> @@ -22,6 +22,18 @@
> */
> #define S3C_FB_MAX_WIN (5)
>
> +/* struct s3cfb_window_pos
> + * @win_pos_x: X-coordinate of window from the left.
> + * @win_pos_y: Y-coordinate of window from the top.
> + */
> +struct s3cfb_window_pos {
> + int win_pos_x;
> + int win_pos_y;
> +};
> +
> +/* Custom ioctl */
> +#define S3CFB_WIN_POSITION _IOW('F', 1, struct s3cfb_window_pos)
Can you change the number from 1 to 203 as follows?
+#define S3CFB_WIN_POSITION _IOW('F', 203, struct s3cfb_window_pos)
We already use this number as S3CFB_WIN_POSITION.
> +
> /**
> * struct s3c_fb_pd_win - per window setup data
> * @win_mode: The display parameters to initialise (not for window 0)
> @@ -35,6 +47,8 @@ struct s3c_fb_pd_win {
> unsigned short max_bpp;
> unsigned short virtual_x;
> unsigned short virtual_y;
> +
> + struct s3cfb_window_pos winpos;
> };
>
> /**
> --
> 1.7.0.4
^ permalink raw reply [flat|nested] 35+ messages in thread* RE: [PATCH 1/2] ARM: SAMSUNG: Add Window Positioning Support for
@ 2011-08-26 5:56 ` Jingoo Han
0 siblings, 0 replies; 35+ messages in thread
From: Jingoo Han @ 2011-08-26 5:56 UTC (permalink / raw)
To: AJAY KUMAR RAMAKRISHNA SHYMALAMMA
Cc: linux-samsung-soc@vger.kernel.org, linux-fbdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, FlorianSchandinat@gmx.de,
lethal@linux-sh.org, Jingoo Han, Marek Szyprowski,
ben-linux@fluff.org, BANAJIT GOSWAMI
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 2118 bytes --]
Hi, Ajay.
> -----Original Message-----
> From: Ajay Kumar [mailto:ajaykumar.rs@samsung.com]
> Sent: Friday, August 26, 2011 4:52 AM
> To: linux-samsung-soc@vger.kernel.org; linux-fbdev@vger.kernel.org; linux-
> arm-kernel@lists.infradead.org
> Cc: FlorianSchandinat@gmx.de; lethal@linux-sh.org; jg1.han@samsung.com;
> m.szyprowski@samsung.com; ben-linux@fluff.org; banajit.g@samsung.com
> Subject: [PATCH 1/2] ARM: SAMSUNG: Add Window Positioning Support for s3c-
> fb driver
>
> This patch:
> --adds a data-structure to hold the current position of windows.
> --adds an ioctl number to support dynamic positioning the windows.
>
> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
> ---
> arch/arm/plat-samsung/include/plat/fb.h | 14 ++++++++++++++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-samsung/include/plat/fb.h b/arch/arm/plat-
> samsung/include/plat/fb.h
> index bd79c0a..77ed75c 100644
> --- a/arch/arm/plat-samsung/include/plat/fb.h
> +++ b/arch/arm/plat-samsung/include/plat/fb.h
> @@ -22,6 +22,18 @@
> */
> #define S3C_FB_MAX_WIN (5)
>
> +/* struct s3cfb_window_pos
> + * @win_pos_x: X-coordinate of window from the left.
> + * @win_pos_y: Y-coordinate of window from the top.
> + */
> +struct s3cfb_window_pos {
> + int win_pos_x;
> + int win_pos_y;
> +};
> +
> +/* Custom ioctl */
> +#define S3CFB_WIN_POSITION _IOW('F', 1, struct s3cfb_window_pos)
Can you change the number from 1 to 203 as follows?
+#define S3CFB_WIN_POSITION _IOW('F', 203, struct s3cfb_window_pos)
We already use this number as S3CFB_WIN_POSITION.
> +
> /**
> * struct s3c_fb_pd_win - per window setup data
> * @win_mode: The display parameters to initialise (not for window 0)
> @@ -35,6 +47,8 @@ struct s3c_fb_pd_win {
> unsigned short max_bpp;
> unsigned short virtual_x;
> unsigned short virtual_y;
> +
> + struct s3cfb_window_pos winpos;
> };
>
> /**
> --
> 1.7.0.4
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ýöÝzÿâžØ^n‡r¡ö¦zË\x1aëh™¨èÚ&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~††Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm
^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2011-09-18 20:39 UTC | newest]
Thread overview: 35+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-08-25 13:54 [PATCH 0/2] video: s3c-fb: Add window positioning support Ajay Kumar
2011-08-25 19:51 ` Ajay Kumar
2011-08-25 19:51 ` Ajay Kumar
2011-08-25 13:54 ` [PATCH 1/2] ARM: SAMSUNG: Add Window Positioning Support for s3c-fb Ajay Kumar
2011-08-25 19:51 ` [PATCH 1/2] ARM: SAMSUNG: Add Window Positioning Support for s3c-fb driver Ajay Kumar
2011-08-25 19:51 ` Ajay Kumar
2011-08-25 13:54 ` [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window Ajay Kumar
2011-08-25 19:51 ` [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window positioning Ajay Kumar
2011-08-25 19:51 ` Ajay Kumar
2011-09-01 16:45 ` [PATCH 0/2] video: s3c-fb: Add window positioning support Florian Tobias Schandinat
2011-09-01 16:45 ` Florian Tobias Schandinat
2011-09-01 16:45 ` Florian Tobias Schandinat
2011-09-02 9:58 ` Tomi Valkeinen
2011-09-02 9:58 ` Tomi Valkeinen
2011-09-02 9:58 ` Tomi Valkeinen
2011-09-06 14:16 ` Ajay kumar
2011-09-06 14:28 ` Ajay kumar
2011-09-06 14:16 ` Ajay kumar
2011-09-07 15:31 ` Laurent Pinchart
2011-09-07 15:31 ` Laurent Pinchart
2011-09-07 15:31 ` Laurent Pinchart
2011-09-07 15:31 ` Laurent Pinchart
2011-09-18 19:29 ` Florian Tobias Schandinat
2011-09-18 19:29 ` Florian Tobias Schandinat
2011-09-18 19:29 ` Florian Tobias Schandinat
2011-09-18 20:39 ` Laurent Pinchart
2011-09-18 20:39 ` Laurent Pinchart
2011-09-18 20:39 ` Laurent Pinchart
-- strict thread matches above, loose matches on Subject: below --
2011-08-26 0:44 [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window positioning JinGoo Han
2011-08-26 0:44 ` [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window JinGoo Han
2011-08-26 5:21 ` [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window positioning Ajay kumar
2011-08-26 5:33 ` Ajay kumar
2011-08-26 5:21 ` Ajay kumar
2011-08-26 5:56 [PATCH 1/2] ARM: SAMSUNG: Add Window Positioning Support for s3c-fb driver Jingoo Han
2011-08-26 5:56 ` [PATCH 1/2] ARM: SAMSUNG: Add Window Positioning Support for Jingoo Han
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.