[BUG] Framebuffer driver is sent unknown IOCTL causing error message if graphics debug enabled

[TimJTi]

Description / Steps to reproduce the issue

I enabled graphics debug while developing a new example NuttX App and find that the framebuffer driver (drivers/video/fb.c) is receiving an unsupported IOCTL (with value 778 which I think is FIONBIO) during the spawning of nsh.

I don't understand why it would be sent this and/or if fb.c should just gracefully accept this ioctl and ignore it with no error?

Call stack is:

fb_ioctl@0x2002ab7c (nuttx/drivers/video/fb.c:1159)
file_vioctl@0x200452e8 (nuttx/fs/vfs/fs_ioctl.c:70)
file_ioctl@0x20045650 (nuttx/fs/vfs/fs_ioctl.c:227)
file_dup3@0x20045190 (nuttx/fs/vfs/fs_dup2.c:148)
file_dup2@0x20045214 (nuttx/fs/vfs/fs_dup2.c:198)
files_duplist@0x2004416c (nuttx/fs/inode/fs_files.c:726)
group_setuptaskfiles@0x20014080 (nuttx/sched/group/group_setuptaskfiles.c:86)
nxtask_init@0x20010b90 (nuttx/sched/task/task_init.c:143)
exec_module@0x2006962c (nuttx/binfmt/binfmt_execmodule.c:319)
exec_internal@0x20068e24 (nuttx/binfmt/binfmt_exec.c:146)
exec_spawn@0x20068ee4 (nuttx/nuttx/binfmt/binfmt_exec.c:225)
nxposix_spawn_exec@0x2005259c (nuttx/sched/task/task_posixspawn.c:109)
posix_spawn@0x2005263c (nuttx/sched/task/task_posixspawn.c:223)
fbcon_main@0x2004338c (nuttx/apps/examples/fbcon/fbcon_main.c:2618)
nxtask_startup@0x2002e08c (nuttx/libs/libc/sched/task_startup.c:72)
nxtask_start@0x200119fc (nuttx/sched/task/task_start.c:116)

On which OS does this issue occur?

[OS: Linux]

What is the version of your OS?

Ubuntu

NuttX Version

master

Issue Architecture

[Arch: arm]

Issue Area

[Area: Drivers]

Host information

No response

Verification

• I have verified before submitting the report.

[xiaoxiang781216]

Yes, the driver should return -ENOTTY for the unknown ioctl number.

[TimJTi]

Yes, the driver should return -ENOTTY for the unknown ioctl number.

@xiaoxiang781216 but it seems wrong that DEBUG is reporting it as an error? That implies the higher level software expects it to work but it doesn't so it is an error. Maybe it should never be sent this ioctl?

Why would file_dup (or earlier functions imn the call stack: not sure where it originates) try and send an unsupported ioctl? And if this behaviour is normal - for this particular ioctl - and OK, then the driver should not report an error?

It seems plain wrong to me.

[xiaoxiang781216]

the high level software should expect -ENOTTY if it send ioctl blindly to an unkown device

[TimJTi]

So either the frame buffer driver shouldn't have a debug error message here, or the higher level has no business sending this ioctl?