Raspberry Pi Rtems-Graphical-Toolkit

Mon May 21 16:59:15 UTC 2018

On Mon, May 21, 2018 at 11:48 AM, Kirspel, Kevin <Kevin-Kirspel at idexx.com>
wrote:

> I think that is doable for the frame buffer and non-USB touch screen,
> mouse, and keyboard drivers.  The main problem would be the USB mouse,
> keyboard, and touch screen drivers.  RTEMS uses LIBBSD for the USB stack.
>

Posting inline below

>
>
> Kevin Kirspel
>
> Electrical Engineer - Sr. Staff
>
> Idexx Roswell
>
> 235 Hembree Park Drive
>
> Roswell GA 30076
>
> Tel: (770)-510-4444 ext. 81642
>
> Direct: (770)-688-1642
>
> Fax: (770)-510-4445
>
>
>
> *From:* users [mailto:users-bounces at rtems.org] *On Behalf Of *Mikhail
> Svetkin
> *Sent:* Monday, May 21, 2018 12:35 PM
> *To:* Kirspel, Kevin <Kevin-Kirspel at idexx.com>
> *Cc:* users at rtems.org; Emre Cetin <hsnemrecetin at gmail.com>
>
> *Subject:* Re: Raspberry Pi Rtems-Graphical-Toolkit
>
>
>
> So the minimal example of Qt Widgets + RTEMS LIBBSD + EVDEV will be ~24MB.
>
> It is pretty big. If RTEMS has support of EVDEV or libinput it will be
> only ~9MB.
>
>
>
> Qt does not require MMAP, only LinuxFB plugin. I wrote my own QPA plugin
> and it does not need MMAP.
>
>
>
>
>
>
>
>
> Best regards,
> Mikhail
>
>
>
> On 21 May 2018 at 17:42, Kirspel, Kevin <Kevin-Kirspel at idexx.com> wrote:
>
> To give a little background on this subject, the current support in RTEMS
> LIBBSD for the EVDEV input system was motivated by the following:
>
>
>
> - Add a “rtems-arm-4.12-gcc” platform to QT.  This allows you to configure
> QT with RTEMS compilers and libraries.
>
> - Use QT LinuxFB plugin as is for graphics output and system input.
>
>
>
> The QT LinuxFB plugin supports the following input systems: libinput,
> tslib, and EVDEV.  I choose EVDEV because it is supported by LIBBSD.
>
>
>
> --------
>
> As a quick indication of footprint, the EVDEV test in the RTEMS LIBBSD
> test suite is ~4 times the size of the hello world test.  I compiled
> against the xilinx_zynq_a9_qemu BSP but the results were similar to my
> custom LPC3250 BSP.  The hello world test is ~4MB.  The EVDEV test is
> ~15MB.  The EVDEV test pulls in the USB keyboard and mouse drivers.  This
> is where most of the footprint increase comes from.  The EVDEV code itself
> is pretty small.  The frame buffer and touch drivers are also small.
>
> That seems large for the normal hello world. Is that the file size or size
reported by "arm-rtems5-size"? I would expect something under 256K no
matter how complex the BSP is. It is often under 48K.

Again is the EVDEV size, file size or real code size?

I agree that having a USB keyboard and mouse requires the FreeBSD stack and
that has code but that much?

>
>
> --------
>
> The frame buffer device in RTEMS is not compatible with QT but it is not
> far off.  QT expects the following Linux headers: “linux/fb.h”,
> “linux/kd.h”, and “sys/kd.h”.  I had ported the Linux headers and placed
> them under the “dev/include/linux” and “dev/include/linux/sys” directories
> in the RTEMS source tree (not currently in the tree because the patches
> were rejected).  QT also expects the frame buffer device to support the
> MMAP device handler.  This was added to Gedare’s MMAP work but as Sebastian
> pointed out it does not follow the design module.  This probably needs to
> be dealt with at some point.
>
>
>
> --------
>
> Right now, the only example on how to use EVDEV is in the LIBBSD test
> suite (evdev01).  I guess the QT source can also be used as an example.
>
>
>
> Kevin Kirspel
>
> Electrical Engineer - Sr. Staff
>
> Idexx Roswell
>
> 235 Hembree Park Drive
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__maps.google.com_-3Fq-3D235-2BHembree-2BPark-2BDrive-2B-250D-250A-2BRoswell-2BGA-2B30076-26entry-3Dgmail-26source-3Dg&d=DwMFaQ&c=2do6VJGs3LvEOe4OFFM1bA&r=dbavT-WIJ4nBfQFKYnKdAD52Vyq3ZXSzrL9TAm21lZI&m=pNtc9XwM_Um_y7szn11M51nwp2ESm43_FnaEfLoDrVE&s=4DbjexY91IzNSksLounr94j_irJaI8pnAqf29Wc2q6g&e=>
>
> Roswell GA 30076
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__maps.google.com_-3Fq-3D235-2BHembree-2BPark-2BDrive-2B-250D-250A-2BRoswell-2BGA-2B30076-26entry-3Dgmail-26source-3Dg&d=DwMFaQ&c=2do6VJGs3LvEOe4OFFM1bA&r=dbavT-WIJ4nBfQFKYnKdAD52Vyq3ZXSzrL9TAm21lZI&m=pNtc9XwM_Um_y7szn11M51nwp2ESm43_FnaEfLoDrVE&s=4DbjexY91IzNSksLounr94j_irJaI8pnAqf29Wc2q6g&e=>
>
> Tel: (770)-510-4444 ext. 81642
>
> Direct: (770)-688-1642
>
> Fax: (770)-510-4445
>
>
>
> *From:* Joel Sherrill [mailto:joel at rtems.org]
> *Sent:* Monday, May 21, 2018 9:10 AM
> *To:* Kirspel, Kevin <Kevin-Kirspel at idexx.com>
> *Cc:* Chris Johns <chrisj at rtems.org>; Mikhail Svetkin <
> mikhail.svetkin at gmail.com>; users at rtems.org; Emre Cetin <
> hsnemrecetin at gmail.com>
>
>
> *Subject:* Re: Raspberry Pi Rtems-Graphical-Toolkit
>
>
>
>
>
> On Mon, May 21, 2018, 7:52 AM Kirspel, Kevin <Kevin-Kirspel at idexx.com>
> wrote:
>
> RTEMS LIBBSD has support for EVDEV which is a standard API for keyboard,
> mouse, and touchscreen.  Is it the best choice, I don't know.  Maybe a
> better question is "What standard input system should RTEMS support?".
>
>
>
> That's the question.
>
>
>
> Using the FreeBSD support has a number of advantages but I admit that I
> didn't know that support was in place. I have no idea what minimum
> footprint using that implies even if you don't use the TCP IP stack.
>
>
>
> In the cpukit there has long been support for a frame buffer device
> framework and a mouse input parsing library. I expect the FreeBSD support
> comes with specific device support that this is weak on.
>
>
>
> But footprint is important. Any idea how large a simple non-networked
> example would be with the FreeBSD code as a base?
>
>
>
> And we need examples and howtos. If I didn't know about it, it isn't
> reasonable to expect someone new to find it. :(
>
>
>
> --joel
>
>
>
>
>
>
>
>
> Kevin Kirspel
> Electrical Engineer - Sr. Staff
> Idexx Roswell
> 235 Hembree Park Drive
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__maps.google.com_-3Fq-3D235-2BHembree-2BPark-2BDrive-2B-250D-250ARoswell-2BGA-2B30076-26entry-3Dgmail-26source-3Dg&d=DwMFaQ&c=2do6VJGs3LvEOe4OFFM1bA&r=dbavT-WIJ4nBfQFKYnKdAD52Vyq3ZXSzrL9TAm21lZI&m=pNtc9XwM_Um_y7szn11M51nwp2ESm43_FnaEfLoDrVE&s=kmmgT8zilp8a-ibdkTczWMS4Xv4e9XPymmkZcbMl88A&e=>
> Roswell GA 30076
> Tel: (770)-510-4444 ext. 81642
> Direct: (770)-688-1642
> Fax: (770)-510-4445
>
> -----Original Message-----
> From: Chris Johns [mailto:chrisj at rtems.org]
> Sent: Sunday, May 20, 2018 5:51 PM
> To: Mikhail Svetkin <mikhail.svetkin at gmail.com>; Kirspel, Kevin <
> Kevin-Kirspel at idexx.com>
> Cc: users at rtems.org; Emre Cetin <hsnemrecetin at gmail.com>
> Subject: Re: Raspberry Pi Rtems-Graphical-Toolkit
>
> On 16/5/18 9:39 pm, Mikhail Svetkin wrote:
> >
> > I think it will be very good if RTEMS has some kind of input subsystem
> > (keyboards,  mouse, touchscreen) with standard API.
> >
>
> Do you have an example standard API what would be suitable?
>
> Chris
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_users&d=DwMFaQ&c=2do6VJGs3LvEOe4OFFM1bA&r=HDiJ93ANMEQ32G5JGdpyUxbdebuwKHBbeiHMr3RbR74&m=jEekgiYvWnHgpNcfJlW6X1x8cM7ASFHxgW29on-cOD8&s=fUSHJbQR5SY1RqkgGuU3VIaH-gUdvMJCG2Pr-VhNXNQ&e=>
>
>
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20180521/8e4f9e30/attachment.html>