Re: [nuttx] Wiki Backup

[Brennan Ashton]

Did another major round of updates.  I removed a few pages that just linked
to documentation pages that are already linked in the documentation
section.  We need to figure out what to do with what is in the
documentation section.
For PDFs and the like we can just attach them to the Documentation page and
then link them in the individual pages, but for the HTML if is a pain to
render the images as well.  I did a hack on the graphics one to replace the
image url, but it is not ideal.

There are also places like this where there is a link to download, and that
should be replaced with an attachment.
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629542

You can also use click Page Info to view all the external links for a
page.  For example there is a nuttx.org and three youtube links here
https://cwiki.apache.org/confluence/pages/viewinfo.action?pageId=139629542

Also about the long URLs Confluence also will generate the short link:

https://cwiki.apache.org/confluence/x/5pNSC


There are some pages where the import did some goofy things like putting
each line of a code block it its own block, but it is very rare and still
readable.

If others want to help review and fix formatting please do.

Justin, I'll ask INFRA if they can fix the space name.

Thanks,
Brennan


On Mon, Dec 16, 2019 at 12:12 PM David Sidrane 
wrote:

> Brennan,
>
> I bet it was grueling. Thank you again Brennan!
>
> David
> -Original Message-
> From: Brennan Ashton [mailto:bash...@brennanashton.com]
> Sent: Monday, December 16, 2019 7:50 AM
> To: dev@nuttx.apache.org
> Subject: Re: [nuttx] Wiki Backup
>
> Greg and David,
> The page names just need to finish getting updated, I did about 80% of
> them. I can finish that today, I just needed to go to sleep last night.
> Manually clicking through all the pages was grating on me.
>
> --Brennan
>
> On Mon, Dec 16, 2019, 3:21 AM David Sidrane 
> wrote:
>
> > Brennan,
> >
> > Thank you for your efforts!
> >
> > Justin: Is there an issue with adding all the PPMC to have the ability to
> > edit the content?
> >
> > I see some naming that looks like url id became the Page Title:
> >
> >  For example: NuttX Initialization Sequence is listed under Initsequence
> >
> > https://cwiki.apache.org/confluence/display/NUTTXTEST/Initsequence
> >
> > Also is there a way to maintain the original authors?
> >
> > David
> >
> > -Original Message-
> > From: Brennan Ashton [mailto:bash...@brennanashton.com]
> > Sent: Sunday, December 15, 2019 11:16 PM
> > To: dev@nuttx.apache.org
> > Subject: Re: [nuttx] Wiki Backup
> >
> > Ok,
> > That was a bigger hassle than I expected.  The converter tool was getting
> > tripped up with odd escaping and generating bad XML files for confluence,
> > but I think it is good now.
> > I also went through and manually cleaned the naming, obvious issues, and
> > inserted a bunch of confluence macros on the pages.
> >
> > https://cwiki.apache.org/confluence/display/NUTTXTEST/Nuttx
> >
> > I think it is good to go live, but there are a few things to address:
> > 1) There are some links that were not wiki links, but url links to the
> > wiki
> > that did not get converted.  I have the sources to find all of these, so
> I
> > will tackle that soon.
> > 2a) The documentation pages are embedding the HTML documentation that is
> > on
> > nuttx.org/Documentation but once the code is moved to github/apache I
> will
> > update to pull the latest.
> > 2b) The documentation is using favicons internally as images, this is not
> > valid and causes issues broken image links.  This should be fixed in the
> > code no changes are needed on the wiki.
> > 3) The presentations are linked to pdfs at nuttx.org Those PDFs should
> > just
> > become attachments to wiki pages.
> >
> > Justin if you move this to NUTTX from NUTTXTEST please add me to the
> > permissions on that space as well.
> >
> > Thanks,
> > Brennan
> >
> > On Sun, Dec 15, 2019 at 4:27 PM Gregory Nutt 
> wrote:
> >
> > >
> > > > First stab at the import went surprisingly well.  All but a few pages
> > > > converted, unfortunately the hierarchy did not convert correctly so I
> > > will
> > > > have to mess with it more (these tools are mostly abandoned for 8+
> > years
> > > so
> > > > at least they run).
> > > That is good news.
> > > > Greg I dont think I will need the other non wiki files since they
> were
> > > not
> > > > wiki attachments they are just external links, we will just have to
> > > > manually re-import them which should be easy enough.
> > >
> > > I am about ready to go upstairs where the internet is good and I will
> > > still transfer them.  They might come in handy for you.
> > >
> > > Greg
> > >
> > >
> > >
> > >
> >
>

[REQUIREMENTS- NuttX Workflow]

[david . sidrane]

 [REQUIREMENTS- NuttX Workflow]

I am creating this thread to gather ONLY REQUIREMENTS. See [DISCUSS - NuttX
Workflow]

After the requirements are gathered in one place we can discuss the merits
and vote on them.

Mentors -> Access to Incubator SVN?

[Flavio Junqueira]

I wanted to confirm that all mentors have access to the incubator SVN. Justin 
McLean clearly does. Could Junping Du and Mohammad Asif Siddiqui confirm that 
they have Incubator SVN access?

Thanks,
-Flavio

nxgl Redrawing

[Dave Marples]

Folks,

I've implemented an ePaper driver under nxgl, but as some of you are 
probably aware there needs to be an explicit redraw request to update an 
ePaper display.


I'm not quite sure how to do that under nxgl as normally it would be 
driven automatically. It also takes a fair bit of time (~14 seconds for 
a colour display) during which period access to the ePaper is 'locked 
out' so the application really does need to be aware of what is going on.


My intention is to add an nx_updatedisplay() API...but is there a 
better, or already available, way to do this? It could be done via a 
call to nx_setvisibility on the background window I guess, but 
personally I don't like overlaid semantics like that...


Regards

DAVE

RE: [nuttx] Wiki Backup

[David Sidrane]

Looking good! Thank you Brennan!

-Original Message-
From: Brennan Ashton [mailto:bash...@brennanashton.com]
Sent: Tuesday, December 17, 2019 1:21 AM
To: dev@nuttx.apache.org
Subject: Re: [nuttx] Wiki Backup

Did another major round of updates.  I removed a few pages that just linked
to documentation pages that are already linked in the documentation
section.  We need to figure out what to do with what is in the
documentation section.
For PDFs and the like we can just attach them to the Documentation page and
then link them in the individual pages, but for the HTML if is a pain to
render the images as well.  I did a hack on the graphics one to replace the
image url, but it is not ideal.

There are also places like this where there is a link to download, and that
should be replaced with an attachment.
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629542

You can also use click Page Info to view all the external links for a
page.  For example there is a nuttx.org and three youtube links here
https://cwiki.apache.org/confluence/pages/viewinfo.action?pageId=139629542

Also about the long URLs Confluence also will generate the short link:

https://cwiki.apache.org/confluence/x/5pNSC


There are some pages where the import did some goofy things like putting
each line of a code block it its own block, but it is very rare and still
readable.

If others want to help review and fix formatting please do.

Justin, I'll ask INFRA if they can fix the space name.

Thanks,
Brennan


On Mon, Dec 16, 2019 at 12:12 PM David Sidrane 
wrote:

> Brennan,
>
> I bet it was grueling. Thank you again Brennan!
>
> David
> -Original Message-
> From: Brennan Ashton [mailto:bash...@brennanashton.com]
> Sent: Monday, December 16, 2019 7:50 AM
> To: dev@nuttx.apache.org
> Subject: Re: [nuttx] Wiki Backup
>
> Greg and David,
> The page names just need to finish getting updated, I did about 80% of
> them. I can finish that today, I just needed to go to sleep last night.
> Manually clicking through all the pages was grating on me.
>
> --Brennan
>
> On Mon, Dec 16, 2019, 3:21 AM David Sidrane 
> wrote:
>
> > Brennan,
> >
> > Thank you for your efforts!
> >
> > Justin: Is there an issue with adding all the PPMC to have the ability
> > to
> > edit the content?
> >
> > I see some naming that looks like url id became the Page Title:
> >
> >  For example: NuttX Initialization Sequence is listed under Initsequence
> >
> > https://cwiki.apache.org/confluence/display/NUTTXTEST/Initsequence
> >
> > Also is there a way to maintain the original authors?
> >
> > David
> >
> > -Original Message-
> > From: Brennan Ashton [mailto:bash...@brennanashton.com]
> > Sent: Sunday, December 15, 2019 11:16 PM
> > To: dev@nuttx.apache.org
> > Subject: Re: [nuttx] Wiki Backup
> >
> > Ok,
> > That was a bigger hassle than I expected.  The converter tool was
> > getting
> > tripped up with odd escaping and generating bad XML files for
> > confluence,
> > but I think it is good now.
> > I also went through and manually cleaned the naming, obvious issues, and
> > inserted a bunch of confluence macros on the pages.
> >
> > https://cwiki.apache.org/confluence/display/NUTTXTEST/Nuttx
> >
> > I think it is good to go live, but there are a few things to address:
> > 1) There are some links that were not wiki links, but url links to the
> > wiki
> > that did not get converted.  I have the sources to find all of these, so
> I
> > will tackle that soon.
> > 2a) The documentation pages are embedding the HTML documentation that is
> > on
> > nuttx.org/Documentation but once the code is moved to github/apache I
> will
> > update to pull the latest.
> > 2b) The documentation is using favicons internally as images, this is
> > not
> > valid and causes issues broken image links.  This should be fixed in the
> > code no changes are needed on the wiki.
> > 3) The presentations are linked to pdfs at nuttx.org Those PDFs should
> > just
> > become attachments to wiki pages.
> >
> > Justin if you move this to NUTTX from NUTTXTEST please add me to the
> > permissions on that space as well.
> >
> > Thanks,
> > Brennan
> >
> > On Sun, Dec 15, 2019 at 4:27 PM Gregory Nutt 
> wrote:
> >
> > >
> > > > First stab at the import went surprisingly well.  All but a few
> > > > pages
> > > > converted, unfortunately the hierarchy did not convert correctly so
> > > > I
> > > will
> > > > have to mess with it more (these tools are mostly abandoned for 8+
> > years
> > > so
> > > > at least they run).
> > > That is good news.
> > > > Greg I dont think I will need the other non wiki files since they
> were
> > > not
> > > > wiki attachments they are just external links, we will just have to
> > > > manually re-import them which should be easy enough.
> > >
> > > I am about ready to go upstairs where the internet is good and I will
> > > still transfer them.  They might come in handy for you.
> > >
> > > Greg
> > >
>

Re: nxgl Redrawing

[Alan Carvalho de Assis]

Hi Dave,

On 12/17/19, Dave Marples  wrote:
> Folks,
>
> I've implemented an ePaper driver under nxgl, but as some of you are
> probably aware there needs to be an explicit redraw request to update an
> ePaper display.
>

Other guy already used ePaper with NX Graphic libs, if I'm not wrong
it was Petteri Aimonen.

He also used NuttX nxgl in his Master Thesis:

http://jpa.kapsi.fi/stuff/other/diplomityo.pdf

> I'm not quite sure how to do that under nxgl as normally it would be
> driven automatically. It also takes a fair bit of time (~14 seconds for
> a colour display) during which period access to the ePaper is 'locked
> out' so the application really does need to be aware of what is going on.
>
> My intention is to add an nx_updatedisplay() API...but is there a
> better, or already available, way to do this? It could be done via a
> call to nx_setvisibility on the background window I guess, but
> personally I don't like overlaid semantics like that...
>

I'm not expert on graphics, but I think you can use the redraw in the
nx_callback to do it.

Please take a look at apps/examples/nxlines, mainly on it:

const struct nx_callback_s g_nxlinescb =
{
  nxlines_redraw,   /* redraw */
...

BR,

Alan

Re: nxgl Redrawing

[Dave Marples]

Hi Alan,

I'm no expert on this stuff either but as I understand things the 
nx_callback/redraw, is for when nx requests that the client redraws a 
portion of the screen (See 2.3.4.1 of the NX Graphics Subsystem manual). 
I want to go the other way - when the application has decided that a new 
display is 'stable', it requests for it to be put on the screen.


I don't really see how to do that in a standard way yet, so I've added a 
new method to lcd.c::struct lcd_dev_s called 'redraw', but I don't want 
to be making extensions to APIs without there being some element of 
discussion first...


Regards

DAVE


On 17/12/2019 11:34, Alan Carvalho de Assis wrote:

Hi Dave,

On 12/17/19, Dave Marples  wrote:

Folks,

I've implemented an ePaper driver under nxgl, but as some of you are
probably aware there needs to be an explicit redraw request to update an
ePaper display.


Other guy already used ePaper with NX Graphic libs, if I'm not wrong
it was Petteri Aimonen.

He also used NuttX nxgl in his Master Thesis:

http://jpa.kapsi.fi/stuff/other/diplomityo.pdf


I'm not quite sure how to do that under nxgl as normally it would be
driven automatically. It also takes a fair bit of time (~14 seconds for
a colour display) during which period access to the ePaper is 'locked
out' so the application really does need to be aware of what is going on.

My intention is to add an nx_updatedisplay() API...but is there a
better, or already available, way to do this? It could be done via a
call to nx_setvisibility on the background window I guess, but
personally I don't like overlaid semantics like that...


I'm not expert on graphics, but I think you can use the redraw in the
nx_callback to do it.

Please take a look at apps/examples/nxlines, mainly on it:

const struct nx_callback_s g_nxlinescb =
{
   nxlines_redraw,   /* redraw */
...

BR,

Alan

Re: nxgl Redrawing

[Dave Marples]

Hmm...going further, the only way I see to deal with this at the nxgl 
layer above the lcd structure itself is to add a nx_redraw with 
corresponding NX_EVENT_REDRAWING/NXEVENT_REDRAWN event callbacks, but 
that makes the nxgl layer device-aware...I don't see how it can't be 
really, these things are pretty different to traditional LCDs. For the 
case of the lcd nx_updatedisplay member not being present I would just 
return the NXEVENT_REDRAWN immediately so everything would remain 
back-compatible.


I don't really see any way to avoid this. Greg, any suggestions for a 
better approach?


Regards

DAVE

On 17/12/2019 10:56, Dave Marples wrote:

Folks,

I've implemented an ePaper driver under nxgl, but as some of you are 
probably aware there needs to be an explicit redraw request to update 
an ePaper display.


I'm not quite sure how to do that under nxgl as normally it would be 
driven automatically. It also takes a fair bit of time (~14 seconds 
for a colour display) during which period access to the ePaper is 
'locked out' so the application really does need to be aware of what 
is going on.


My intention is to add an nx_updatedisplay() API...but is there a 
better, or already available, way to do this? It could be done via a 
call to nx_setvisibility on the background window I guess, but 
personally I don't like overlaid semantics like that...


Regards

DAVE

Re: nxgl Redrawing

[Gregory Nutt]

I need to understand more before I could comment.


I've implemented an ePaper driver under nxgl, but as some of you are 
probably aware there needs to be an explicit redraw request to update 
an ePaper display.
What is the interface to the ePaper device?  Is it through a serial 
interface?  Or a framebuffer interface?
I'm not quite sure how to do that under nxgl as normally it would be 
driven automatically. It also takes a fair bit of time (~14 seconds 
for a colour display) during which period access to the ePaper is 
'locked out' so the application really does need to be aware of what 
is going on.


What do you might by NXGL?  It is library of simply drawing helpers.  I 
take it you are not using NX, the full graphics system.  It would update 
automatically and we would not be having this discussion.


Since you are redrawing something that was not drawn by NX, it must be 
something that you drew in your application?  True?  Are you using a 
software framebuffer?


The correct way to implement a software framebuffer driver for a serial 
graphics device is via drivers/lcd/lcd_framebuffer.c.  That driver will 
allocate the software framebuffer and export a standard NuttX 
framebuffer driver interface.  The framebuffer driver at 
drivers/video/fb.c will expose the framebuffer driver to the 
application.  From the framebuffer driver you can use the FIOC_MMAP 
IOCTL command to get the address of the framebuffer. You would need 
enable CONFIG_LCD_UPDATE, then you can use FBIO_UPDATE command to force 
the software software framebuffer to be written to the serial hardware.


Here are some examples:

$ find boards -name defconfig | xargs grep CONFIG_LCD_FRAMEBUFFER
boards/arm/stm32/stm3240g-eval/configs/fb/defconfig:CONFIG_LCD_FRAMEBUFFER=y
boards/arm/stm32/stm32f4discovery/configs/max7219/defconfig:CONFIG_LCD_FRAMEBUFFER=y
boards/arm/stm32l4/nucleo-l476rg/configs/nxdemo/defconfig:CONFIG_LCD_FRAMEBUFFER=y

My intention is to add an nx_updatedisplay() API...but is there a 
better, or already available, way to do this? It could be done via a 
call to nx_setvisibility on the background window I guess, but 
personally I don't like overlaid semantics like that...


Now, that sounds like you are using NX.  NX will automatically update 
the display.


I cannot imagine a situation where that would be necessary. Let's talk 
more before you waste your time.  I would have to understand what you 
are really doing to be able to help you.


Greg

Re: nxgl Redrawing

[Gregory Nutt]

... I want to go the other way - when the application has decided that 
a new display is 'stable', it requests for it to be put on the screen.


I don't understand what that means.  Where is this new display?

Re: nxgl Redrawing

[Gregory Nutt]

I don't really see any way to avoid this. Greg, any suggestions for a 
better approach?


I would needed to understand how you are forming these displays, where 
the display resides (in application memory), and how you are interfacing 
from the "display" to hardware.  I really don't have a clue what you are 
doing.  We are not communicating.

Re: nxgl Redrawing

[Gregory Nutt]

Hmm...going further, the only way I see to deal with this at the nxgl 
layer above the lcd structure itself is to add a nx_redraw with 
corresponding NX_EVENT_REDRAWING/NXEVENT_REDRAWN event callbacks, but 
that makes the nxgl layer device-aware...I don't see how it can't be 
really, these things are pretty different to traditional LCDs. For the 
case of the lcd nx_updatedisplay member not being present I would just 
return the NXEVENT_REDRAWN immediately so everything would remain 
back-compatible.


And you don't want to modified in the graphics interface unless you are 
also will to modify and test all of the graphic applications in 
apps/graphics that use it.  There won't be any special change to the 
graphic system to support your case.


If you could explain what you think this nx_displayupdate() function 
would do, that would also be helpful.


Greg

Re: nxgl Redrawing

[Dave Marples]

Hi Greg,

Thanks for the replies.  Comments embedded;

What is the interface to the ePaper device?  Is it through a serial 
interface?  Or a framebuffer interface?
The interface is over SPI. It 'looks like' a normal lcd supported by 
lcd_dev_s. The particular one I have is write-only, but read/write ones 
exist too.


What do you might by NXGL?  It is library of simply drawing helpers.  
I take it you are not using NX, the full graphics system.  It would 
update automatically and we would not be having this discussion.


It's worth explaining a little bit more about how these devices work, 
then it'll be clearer, I hope.


They have a display RAM just like an SPI or I2C interfaced LCD does. You 
write to it in the same way using similar commands.  The difference is 
that the display RAM _does _not_ automatically get transferred onto the 
screen.  That has to be done by a separate operation which, depending on 
the device in question, can take up to 15 seconds or so.


NXGL offers a nice set of drawing primitives which remain applicable to 
these displays. There is no difference to NXGL or the way that it is 
used, and no code in NXGL is changed to allow it to work with ePaper.


Unfortunately, nothing changes on the screen until the send-to-screen 
(redraw) command is issued.




Since you are redrawing something that was not drawn by NX, it must be 
something that you drew in your application?  True?  Are you using a 
software framebuffer?

It was drawn by NX, it just didn't make it to the screen yet.


The correct way to implement a software framebuffer driver for a 
serial graphics device is via drivers/lcd/lcd_framebuffer.c.  That 
driver will allocate the software framebuffer and export a standard 
NuttX framebuffer driver interface.  The framebuffer driver at 
drivers/video/fb.c will expose the framebuffer driver to the 
application.  From the framebuffer driver you can use the FIOC_MMAP 
IOCTL command to get the address of the framebuffer. You would need 
enable CONFIG_LCD_UPDATE, then you can use FBIO_UPDATE command to 
force the software software framebuffer to be written to the serial 
hardware.


A framebuffer isn't needed, as there is already one on the device. 
However, what I need to do is directly equivalent to FBIO_UPDATE. 
Normally FBIO_UPDATE works from NuttX RAM to the LCD (and automatically 
onto the display), I want to go from the ePaper RAM to the display. 
Using the framebuffer wouldn't help me as I'd still need to perform the 
redraw operation to get the stuff onto the actual display after sending 
the FBIO_UPDATE.


Now, that sounds like you are using NX.  NX will automatically update 
the display.


I cannot imagine a situation where that would be necessary. Let's talk 
more before you waste your time.  I would have to understand what you 
are really doing to be able to help you.


NX _thinks_ it's updated the display and indeed, in the normal scheme of 
things (with an LCD), it would have.  Unfortunately, for this class of 
displays, this second step to sync the display ram to the display itself 
is needed.


I've just read through the other notes you've sent. To avoid fragmenting 
my reply;


*) It's an ePaper electrophoretic display which is bi-stable - whatever 
is on the display will stay there, even without power. That means 
transferring the contents of the display frame memory to the display is 
a second step operation which takes a while to happen.


*) I can use nxgl to write to it no problem.  As far as nxgl is 
concerned it looks just like an ILI9341 or similar (different command 
set, but the same principles). The problem is that what is written to it 
does not end up on the display until a separate, time consuming, redraw 
command is issued. While the redraw is going on the display is away with 
the faries and will not communicate at all. That isn't a problem for us 
as new drawing commands will just back up in the NXGL MQ until it 
becomes available again.


*) There is no modification needed to any existing nxgl or other code 
for this to work...it's a simple extension to add this redraw 
command...but I need to be comfortable that I've put it in the right 
place, hence why I'm asking for input. It means that some practical 
details of the implementation of the display technology are 'leaking' up 
into the graphics abstraction, but I don't really see a way to avoid it. 
Only the application knows when it's permissible to take an extended 
time to perform an update.


Regards

DAVE

Re: nxgl Redrawing

[Nathan Hartman]

On Tue, Dec 17, 2019 at 8:44 AM Dave Marples  wrote:

> It means that some practical
> details of the implementation of the display technology are 'leaking' up
> into the graphics abstraction, but I don't really see a way to avoid it.
> Only the application knows when it's permissible to take an extended
> time to perform an update.


How are other operating systems / graphics libraries handling this?

Re: nxgl Redrawing

[Gregory Nutt]

Thanks.  I understand better now.

This is very specific to this hardware.    I don't think this should 
involve the graphics system in such a device-specific way since this is 
a hardware interfacing issue that has nothing to with graphics other 
than a graphics device is involved.  There are easy hacks or complex 
architectural changes to accomplish what you want to do.


For easy hacks, I would suggest a minimal, trivial device driver that 
just supports the the FBIO_UPDATE command (and any other command unique 
to the hardware).  This driver would have to lie in the board-specific 
logic or else have an SPI interface passed to it during initialization.  
Or maybe a boardctl(BOARDIOC_IOCTL) command.


If you wanted to support a graphics driver interface via NX, that is 
okay too.  But we would have to do that right, that is, in a 
device-independent, platform-independent, general way.


A better functional partitioning would be to have this hardware-specific 
functionality implemented inside of the LCD driver, rather than in some 
hack character driver or BOARDIOC_IOCTL.   There is, however, no LCD 
driver interface exposed to the application; the LCD driver interface is 
only available to NX.  I suppose it would be possible to add to an 
ioctl() method to every LCD (or FB) driver and and nx_ioctl() method to 
communicate and device-specific commands with the driver.  But that 
would be a pretty big effort (but a worthwhile contribution).  I would 
help on that one; the other, simpler ideas are basically hacks that 
could give you the functionality you need.  A generic graphics hardware 
IOCTL command would besystematic and general and common to all graphics 
devices.


Greg

On 12/17/2019 7:44 AM, Dave Marples wrote:

Hi Greg,

Thanks for the replies.  Comments embedded;

What is the interface to the ePaper device?  Is it through a serial 
interface?  Or a framebuffer interface?
The interface is over SPI. It 'looks like' a normal lcd supported by 
lcd_dev_s. The particular one I have is write-only, but read/write 
ones exist too.


What do you might by NXGL?  It is library of simply drawing helpers.  
I take it you are not using NX, the full graphics system.  It would 
update automatically and we would not be having this discussion.


It's worth explaining a little bit more about how these devices work, 
then it'll be clearer, I hope.


They have a display RAM just like an SPI or I2C interfaced LCD does. 
You write to it in the same way using similar commands.  The 
difference is that the display RAM _does _not_ automatically get 
transferred onto the screen.  That has to be done by a separate 
operation which, depending on the device in question, can take up to 
15 seconds or so.


NXGL offers a nice set of drawing primitives which remain applicable 
to these displays. There is no difference to NXGL or the way that it 
is used, and no code in NXGL is changed to allow it to work with ePaper.


Unfortunately, nothing changes on the screen until the send-to-screen 
(redraw) command is issued.




Since you are redrawing something that was not drawn by NX, it must 
be something that you drew in your application?  True?  Are you using 
a software framebuffer?

It was drawn by NX, it just didn't make it to the screen yet.


The correct way to implement a software framebuffer driver for a 
serial graphics device is via drivers/lcd/lcd_framebuffer.c. That 
driver will allocate the software framebuffer and export a standard 
NuttX framebuffer driver interface.  The framebuffer driver at 
drivers/video/fb.c will expose the framebuffer driver to the 
application.  From the framebuffer driver you can use the FIOC_MMAP 
IOCTL command to get the address of the framebuffer. You would need 
enable CONFIG_LCD_UPDATE, then you can use FBIO_UPDATE command to 
force the software software framebuffer to be written to the serial 
hardware.


A framebuffer isn't needed, as there is already one on the device. 
However, what I need to do is directly equivalent to FBIO_UPDATE. 
Normally FBIO_UPDATE works from NuttX RAM to the LCD (and 
automatically onto the display), I want to go from the ePaper RAM to 
the display. Using the framebuffer wouldn't help me as I'd still need 
to perform the redraw operation to get the stuff onto the actual 
display after sending the FBIO_UPDATE.


Now, that sounds like you are using NX. NX will automatically update 
the display.


I cannot imagine a situation where that would be necessary. Let's 
talk more before you waste your time.  I would have to understand 
what you are really doing to be able to help you.


NX _thinks_ it's updated the display and indeed, in the normal scheme 
of things (with an LCD), it would have.  Unfortunately, for this class 
of displays, this second step to sync the display ram to the display 
itself is needed.


I've just read through the other notes you've sent. To avoid 
fragmenting my reply;


*) It's an ePaper electrophoretic display which is bi-stable - 
whate

Re: nxgl Redrawing

[Gregory Nutt]

For easy hacks, I would suggest a minimal, trivial device driver that 
just supports the the FBIO_UPDATE command (and any other command 
unique to the hardware).  This driver would have to lie in the 
board-specific logic or else have an SPI interface passed to it during 
initialization.  Or maybe a boardctl(BOARDIOC_IOCTL) command.


Thinking a little more:  There is a serialization problem with using 
these easy hacks.  The communication with NX is asynchronous through a 
message queue (this supports mult-threaded graphics clients).  In order 
to synchronize with the NX server, you would need to do nx_synch() which 
blocks until the SYNC message is processed. l Then you can safely do the 
low level interface.


If you wanted to support a graphics driver interface via NX, that is 
okay too.  But we would have to do that right, that is, in a 
device-independent, platform-independent, general way.


A better functional partitioning would be to have this 
hardware-specific functionality implemented inside of the LCD driver, 
rather than in some hack character driver or BOARDIOC_IOCTL.   There 
is, however, no LCD driver interface exposed to the application; the 
LCD driver interface is only available to NX.  I suppose it would be 
possible to add to an ioctl() method to every LCD (or FB) driver and 
and nx_ioctl() method to communicate and device-specific commands with 
the driver.  But that would be a pretty big effort (but a worthwhile 
contribution).  I would help on that one; the other, simpler ideas are 
basically hacks that could give you the functionality you need.  A 
generic graphics hardware IOCTL command would besystematic and general 
and common to all graphics devices.


An implementation of nx_ioctl() would be queued in order in the message 
queue and would not need any special synchronization.


Greg

Re: nxgl Redrawing

[Alan Carvalho de Assis]

On 12/17/19, Gregory Nutt  wrote:
> Thanks.  I understand better now.
>
> This is very specific to this hardware.I don't think this should
> involve the graphics system in such a device-specific way since this is
> a hardware interfacing issue that has nothing to with graphics other
> than a graphics device is involved.  There are easy hacks or complex
> architectural changes to accomplish what you want to do.
>
> For easy hacks, I would suggest a minimal, trivial device driver that
> just supports the the FBIO_UPDATE command (and any other command unique
> to the hardware).  This driver would have to lie in the board-specific
> logic or else have an SPI interface passed to it during initialization.
> Or maybe a boardctl(BOARDIOC_IOCTL) command.
>
> If you wanted to support a graphics driver interface via NX, that is
> okay too.  But we would have to do that right, that is, in a
> device-independent, platform-independent, general way.
>
> A better functional partitioning would be to have this hardware-specific
> functionality implemented inside of the LCD driver, rather than in some
> hack character driver or BOARDIOC_IOCTL.   There is, however, no LCD
> driver interface exposed to the application; the LCD driver interface is
> only available to NX.  I suppose it would be possible to add to an
> ioctl() method to every LCD (or FB) driver and and nx_ioctl() method to
> communicate and device-specific commands with the driver.  But that
> would be a pretty big effort (but a worthwhile contribution).  I would
> help on that one; the other, simpler ideas are basically hacks that
> could give you the functionality you need.  A generic graphics hardware
> IOCTL command would besystematic and general and common to all graphics
> devices.
>

Let's to follow the usual steps: how does Linux kernel implement the
e-Ink/ePaper driver?

Amazon developed the Kindle (their Lab126) more than 10 years ago and
it uses Linux since its inception. So I think there is a well defined
way to do it.

Well, I didn't find much information about it, but only an old
instruction to this subject:

https://www.networkworld.com/article/2289160/kernel-space--e-paper-support-for-linux.html

BR,

Alan

Re: nxgl Redrawing

[Gregory Nutt]

It means that some practical
details of the implementation of the display technology are 'leaking' up
into the graphics abstraction, but I don't really see a way to avoid it.
Only the application knows when it's permissible to take an extended
time to perform an update.

How are other operating systems / graphics libraries handling this?


I can imagine how minimal RTOS and bare metal solutions would do this -- 
via calls into hodge podge HAL.  But that would not apply to a POSIX OS 
which constrains application interfaces to only portable interfaces.


If Linux/Android supports this device, how they did this would be 
meaningful.  If you provide the display info, I can check of there is 
support by other higher-level OSs.  I generally accept how-linux-does-it 
as good as a specification in lack of any real specification.


[Although I really don't like looking at Linux drivers these days.  The 
Linux driver sub-subsystem has gotten very complex and I stopped keeping 
up with Linux internals years ago].


Greg

RE: Wiki Backup

[Xiang Xiao]

The new wiki look great, thanks your hard work, Brennan!

-Original Message-
From: David Sidrane  
Sent: 2019年12月17日 17:53
To: dev@nuttx.apache.org
Subject: RE: [nuttx] Wiki Backup

Looking good! Thank you Brennan!

-Original Message-
From: Brennan Ashton [mailto:bash...@brennanashton.com]
Sent: Tuesday, December 17, 2019 1:21 AM
To: dev@nuttx.apache.org
Subject: Re: [nuttx] Wiki Backup

Did another major round of updates.  I removed a few pages that just linked to 
documentation pages that are already linked in the documentation section.  We 
need to figure out what to do with what is in the documentation section.
For PDFs and the like we can just attach them to the Documentation page and 
then link them in the individual pages, but for the HTML if is a pain to render 
the images as well.  I did a hack on the graphics one to replace the image url, 
but it is not ideal.

There are also places like this where there is a link to download, and that 
should be replaced with an attachment.
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629542

You can also use click Page Info to view all the external links for a page.  
For example there is a nuttx.org and three youtube links here
https://cwiki.apache.org/confluence/pages/viewinfo.action?pageId=139629542

Also about the long URLs Confluence also will generate the short link:

https://cwiki.apache.org/confluence/x/5pNSC


There are some pages where the import did some goofy things like putting each 
line of a code block it its own block, but it is very rare and still readable.

If others want to help review and fix formatting please do.

Justin, I'll ask INFRA if they can fix the space name.

Thanks,
Brennan


On Mon, Dec 16, 2019 at 12:12 PM David Sidrane 
wrote:

> Brennan,
>
> I bet it was grueling. Thank you again Brennan!
>
> David
> -Original Message-
> From: Brennan Ashton [mailto:bash...@brennanashton.com]
> Sent: Monday, December 16, 2019 7:50 AM
> To: dev@nuttx.apache.org
> Subject: Re: [nuttx] Wiki Backup
>
> Greg and David,
> The page names just need to finish getting updated, I did about 80% of 
> them. I can finish that today, I just needed to go to sleep last night.
> Manually clicking through all the pages was grating on me.
>
> --Brennan
>
> On Mon, Dec 16, 2019, 3:21 AM David Sidrane 
> wrote:
>
> > Brennan,
> >
> > Thank you for your efforts!
> >
> > Justin: Is there an issue with adding all the PPMC to have the 
> > ability to edit the content?
> >
> > I see some naming that looks like url id became the Page Title:
> >
> >  For example: NuttX Initialization Sequence is listed under 
> > Initsequence
> >
> > https://cwiki.apache.org/confluence/display/NUTTXTEST/Initsequence
> >
> > Also is there a way to maintain the original authors?
> >
> > David
> >
> > -Original Message-
> > From: Brennan Ashton [mailto:bash...@brennanashton.com]
> > Sent: Sunday, December 15, 2019 11:16 PM
> > To: dev@nuttx.apache.org
> > Subject: Re: [nuttx] Wiki Backup
> >
> > Ok,
> > That was a bigger hassle than I expected.  The converter tool was 
> > getting tripped up with odd escaping and generating bad XML files 
> > for confluence, but I think it is good now.
> > I also went through and manually cleaned the naming, obvious issues, 
> > and inserted a bunch of confluence macros on the pages.
> >
> > https://cwiki.apache.org/confluence/display/NUTTXTEST/Nuttx
> >
> > I think it is good to go live, but there are a few things to address:
> > 1) There are some links that were not wiki links, but url links to 
> > the wiki that did not get converted.  I have the sources to find all 
> > of these, so
> I
> > will tackle that soon.
> > 2a) The documentation pages are embedding the HTML documentation 
> > that is on nuttx.org/Documentation but once the code is moved to 
> > github/apache I
> will
> > update to pull the latest.
> > 2b) The documentation is using favicons internally as images, this 
> > is not valid and causes issues broken image links.  This should be 
> > fixed in the code no changes are needed on the wiki.
> > 3) The presentations are linked to pdfs at nuttx.org Those PDFs 
> > should just become attachments to wiki pages.
> >
> > Justin if you move this to NUTTX from NUTTXTEST please add me to the 
> > permissions on that space as well.
> >
> > Thanks,
> > Brennan
> >
> > On Sun, Dec 15, 2019 at 4:27 PM Gregory Nutt 
> wrote:
> >
> > >
> > > > First stab at the import went surprisingly well.  All but a few 
> > > > pages converted, unfortunately the hierarchy did not convert 
> > > > correctly so I
> > > will
> > > > have to mess with it more (these tools are mostly abandoned for 
> > > > 8+
> > years
> > > so
> > > > at least they run).
> > > That is good news.
> > > > Greg I dont think I will need the other non wiki files since 
> > > > they
> were
> > > not
> > > > wiki attachments they are just external links, we will just have 
> > > > to manually re-

Re: Wiki Backup

[Alin Jerpelea]

it looks nice
great work

On Tue, Dec 17, 2019, 16:53 Xiang Xiao  wrote:

> The new wiki look great, thanks your hard work, Brennan!
>
> -Original Message-
> From: David Sidrane 
> Sent: 2019年12月17日 17:53
> To: dev@nuttx.apache.org
> Subject: RE: [nuttx] Wiki Backup
>
> Looking good! Thank you Brennan!
>
> -Original Message-
> From: Brennan Ashton [mailto:bash...@brennanashton.com]
> Sent: Tuesday, December 17, 2019 1:21 AM
> To: dev@nuttx.apache.org
> Subject: Re: [nuttx] Wiki Backup
>
> Did another major round of updates.  I removed a few pages that just
> linked to documentation pages that are already linked in the documentation
> section.  We need to figure out what to do with what is in the
> documentation section.
> For PDFs and the like we can just attach them to the Documentation page
> and then link them in the individual pages, but for the HTML if is a pain
> to render the images as well.  I did a hack on the graphics one to replace
> the image url, but it is not ideal.
>
> There are also places like this where there is a link to download, and
> that should be replaced with an attachment.
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629542
>
> You can also use click Page Info to view all the external links for a
> page.  For example there is a nuttx.org and three youtube links here
> https://cwiki.apache.org/confluence/pages/viewinfo.action?pageId=139629542
>
> Also about the long URLs Confluence also will generate the short link:
>
> https://cwiki.apache.org/confluence/x/5pNSC
>
>
> There are some pages where the import did some goofy things like putting
> each line of a code block it its own block, but it is very rare and still
> readable.
>
> If others want to help review and fix formatting please do.
>
> Justin, I'll ask INFRA if they can fix the space name.
>
> Thanks,
> Brennan
> 
>
> On Mon, Dec 16, 2019 at 12:12 PM David Sidrane 
> wrote:
>
> > Brennan,
> >
> > I bet it was grueling. Thank you again Brennan!
> >
> > David
> > -Original Message-
> > From: Brennan Ashton [mailto:bash...@brennanashton.com]
> > Sent: Monday, December 16, 2019 7:50 AM
> > To: dev@nuttx.apache.org
> > Subject: Re: [nuttx] Wiki Backup
> >
> > Greg and David,
> > The page names just need to finish getting updated, I did about 80% of
> > them. I can finish that today, I just needed to go to sleep last night.
> > Manually clicking through all the pages was grating on me.
> >
> > --Brennan
> >
> > On Mon, Dec 16, 2019, 3:21 AM David Sidrane 
> > wrote:
> >
> > > Brennan,
> > >
> > > Thank you for your efforts!
> > >
> > > Justin: Is there an issue with adding all the PPMC to have the
> > > ability to edit the content?
> > >
> > > I see some naming that looks like url id became the Page Title:
> > >
> > >  For example: NuttX Initialization Sequence is listed under
> > > Initsequence
> > >
> > > https://cwiki.apache.org/confluence/display/NUTTXTEST/Initsequence
> > >
> > > Also is there a way to maintain the original authors?
> > >
> > > David
> > >
> > > -Original Message-
> > > From: Brennan Ashton [mailto:bash...@brennanashton.com]
> > > Sent: Sunday, December 15, 2019 11:16 PM
> > > To: dev@nuttx.apache.org
> > > Subject: Re: [nuttx] Wiki Backup
> > >
> > > Ok,
> > > That was a bigger hassle than I expected.  The converter tool was
> > > getting tripped up with odd escaping and generating bad XML files
> > > for confluence, but I think it is good now.
> > > I also went through and manually cleaned the naming, obvious issues,
> > > and inserted a bunch of confluence macros on the pages.
> > >
> > > https://cwiki.apache.org/confluence/display/NUTTXTEST/Nuttx
> > >
> > > I think it is good to go live, but there are a few things to address:
> > > 1) There are some links that were not wiki links, but url links to
> > > the wiki that did not get converted.  I have the sources to find all
> > > of these, so
> > I
> > > will tackle that soon.
> > > 2a) The documentation pages are embedding the HTML documentation
> > > that is on nuttx.org/Documentation but once the code is moved to
> > > github/apache I
> > will
> > > update to pull the latest.
> > > 2b) The documentation is using favicons internally as images, this
> > > is not valid and causes issues broken image links.  This should be
> > > fixed in the code no changes are needed on the wiki.
> > > 3) The presentations are linked to pdfs at nuttx.org Those PDFs
> > > should just become attachments to wiki pages.
> > >
> > > Justin if you move this to NUTTX from NUTTXTEST please add me to the
> > > permissions on that space as well.
> > >
> > > Thanks,
> > > Brennan
> > >
> > > On Sun, Dec 15, 2019 at 4:27 PM Gregory Nutt 
> > wrote:
> > >
> > > >
> > > > > First stab at the import went surprisingly well.  All but a few
> > > > > pages converted, unfortunately the hierarchy did not convert
> > > > > correctly so I
> > > > will
> > > > > have to mess with it more (these 

Re: nxgl Redrawing

[Dave Marples]

How are other operating systems / graphics libraries handling this?



From what I've seen they mostly don't...you end up with a parallel 
graphics subsystem built on top of an SPI. We can do better than that, 
given that very little needs to be extended.


Regards

DAVE

Re: nxgl Redrawing

[Gregory Nutt]

On 12/17/2019 9:03 AM, Dave Marples wrote:



How are other operating systems / graphics libraries handling this?


From what I've seen they mostly don't...you end up with a parallel 
graphics subsystem built on top of an SPI. We can do better than that, 
given that very little needs to be extended. 


Linux uses Xorg for graphics.  So if this feature is supported in Linux, 
then I think it would be through Xorg?  The NX server is the tiny, moral 
equivalent of the XServer.


This is interesting: 
https://hackaday.com/2018/08/14/run-a-linux-terminal-on-cheap-e-ink-displays/ 
The interface is written in Python: https://github.com/joukos/PaperTTY 
but I don't really see anything of interest.


I see a lot of references to "deferred IO" with ePaper devices. AFAIK 
deferred IO is basically what drivers/lcd/lcd_framebuffer.c does:  If 
buffers all writes to the device in a framebuffer.  You could then force 
the framebuffer dump to hardware using the FBIO_UPDATE ioctl in 
drivers/video/fb.c


Sorry... a half hour of Googling did not answer the question for me.

Re: nxgl Redrawing

[Dave Marples]

Linux uses Xorg for graphics.  So if this feature is supported in 
Linux, then I think it would be through Xorg?  The NX server is the 
tiny, moral equivalent of the XServer.


This is interesting: 
https://hackaday.com/2018/08/14/run-a-linux-terminal-on-cheap-e-ink-displays/ 
The interface is written in Python: https://github.com/joukos/PaperTTY 
but I don't really see anything of interest.


I see a lot of references to "deferred IO" with ePaper devices. AFAIK 
deferred IO is basically what drivers/lcd/lcd_framebuffer.c does:  If 
buffers all writes to the device in a framebuffer.  You could then 
force the framebuffer dump to hardware using the FBIO_UPDATE ioctl in 
drivers/video/fb.c


Sorry... a half hour of Googling did not answer the question for me.


I'm not aware of any 'standard' interfaces. Most of the code I've seen 
is hackup bits and pieces, but there's no way I'm going to build a whole 
parallel ecosystem when we've got all the juicy stuff to hand...provided 
we don't break anything to use it!


For interest, you can see the sort of modules I'm using at 
https://www.buydisplay.com/default/e-paper-display-module-e-ink-display-kit-manufacturers/2-7-inch


So, I think the path here is that I'll tidy up what I've done and then 
I'll submit it for comment and kickabout, and see where we go from there.


Regards

DAVE

Re: nxgl Redrawing

[Gregory Nutt]

So, I think the path here is that I'll tidy up what I've done and then 
I'll submit it for comment and kickabout, and see where we go from there. 


If it is not too device specific, I can put it on a branch and we can 
haggle through the details before merging it to master.

patch for ntpclient: merge xmit and recv buffer into one to save the stack

[Xiang Xiao]

another patch  fix warning: 'g_nullstring' defined but not used.

Thanks
Xiang

Re: nxgl Redrawing

[Gregory Nutt]

On 12/17/2019 10:10 AM, Gregory Nutt wrote:


So, I think the path here is that I'll tidy up what I've done and 
then I'll submit it for comment and kickabout, and see where we go 
from there. 


If it is not too device specific, I can put it on a branch and we can 
haggle through the details before merging it to master.
I think your original proposal for nx_updatedisplay() would be okay if  
it were renamed and took three arguments like:


int nx_synch(NXWINDOW hwnd, int cmd, unsigned long arg)

it would be prototyped in include/nuttx/nx/nx.h and there would probably 
need to be a new include/nuttx/nx/nx_ioctl.h to hold IOCTL commands and 
structures.


These are things I can help with.

Greg

Re: patch for ntpclient: merge xmit and recv buffer into one to save the stack

[Gregory Nutt]

another patch  fix warning: 'g_nullstring' defined but not used.

I don't see anything attached.

Re: nxgl Redrawing

[Dave Marples]

If it is not too device specific, I can put it on a branch and we can 
haggle through the details before merging it to master.
I think your original proposal for nx_updatedisplay() would be okay 
if  it were renamed and took three arguments like:


int nx_synch(NXWINDOW hwnd, int cmd, unsigned long arg)

it would be prototyped in include/nuttx/nx/nx.h and there would 
probably need to be a new include/nuttx/nx/nx_ioctl.h to hold IOCTL 
commands and structures.


These are things I can help with.

Greg


Yes, I already did some name changes because they were too close to 
already used terms. Let me build this strawman and then we've got 
something to work from.


Regards

DAVE

Re: patch for ntpclient: merge xmit and recv buffer into one to save the stack

[Xiang Xiao]

It seems that I can't attach the file to dev@nuttx.apache.org:(.
My attachment in previous email also lose:
https://lists.apache.org/thread.html/9bc6f92e39b9d2f401e1554c0e3270d574067ff608d13df1c1c1b11e%40

Justin, can we send the attachment to dev@nuttx.apache.org?

On Wed, Dec 18, 2019 at 12:17 AM Gregory Nutt  wrote:
>
>
> > another patch  fix warning: 'g_nullstring' defined but not used.
> I don't see anything attached.

Re: Wiki Backup

[David S. Alessio]

Brennan,

Great work.  It looks great; and you made it look easy ;)

Cheers,
-david


> On Dec 17, 2019, at 6:43 AM, Xiang Xiao  wrote:
> 
> The new wiki look great, thanks your hard work, Brennan!
> 
> -Original Message-
> From: David Sidrane  
> Sent: 2019年12月17日 17:53
> To: dev@nuttx.apache.org
> Subject: RE: [nuttx] Wiki Backup
> 
> Looking good! Thank you Brennan!
> 
> -Original Message-
> From: Brennan Ashton [mailto:bash...@brennanashton.com]
> Sent: Tuesday, December 17, 2019 1:21 AM
> To: dev@nuttx.apache.org
> Subject: Re: [nuttx] Wiki Backup
> 
> Did another major round of updates.  I removed a few pages that just linked 
> to documentation pages that are already linked in the documentation section.  
> We need to figure out what to do with what is in the documentation section.
> For PDFs and the like we can just attach them to the Documentation page and 
> then link them in the individual pages, but for the HTML if is a pain to 
> render the images as well.  I did a hack on the graphics one to replace the 
> image url, but it is not ideal.
> 
> There are also places like this where there is a link to download, and that 
> should be replaced with an attachment.
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629542
> 
> You can also use click Page Info to view all the external links for a page.  
> For example there is a nuttx.org and three youtube links here
> https://cwiki.apache.org/confluence/pages/viewinfo.action?pageId=139629542
> 
> Also about the long URLs Confluence also will generate the short link:
> 
> https://cwiki.apache.org/confluence/x/5pNSC
> 
> 
> There are some pages where the import did some goofy things like putting each 
> line of a code block it its own block, but it is very rare and still readable.
> 
> If others want to help review and fix formatting please do.
> 
> Justin, I'll ask INFRA if they can fix the space name.
> 
> Thanks,
> Brennan
> 
> 
> On Mon, Dec 16, 2019 at 12:12 PM David Sidrane 
> wrote:
> 
>> Brennan,
>> 
>> I bet it was grueling. Thank you again Brennan!
>> 
>> David
>> -Original Message-
>> From: Brennan Ashton [mailto:bash...@brennanashton.com]
>> Sent: Monday, December 16, 2019 7:50 AM
>> To: dev@nuttx.apache.org
>> Subject: Re: [nuttx] Wiki Backup
>> 
>> Greg and David,
>> The page names just need to finish getting updated, I did about 80% of 
>> them. I can finish that today, I just needed to go to sleep last night.
>> Manually clicking through all the pages was grating on me.
>> 
>> --Brennan
>> 
>> On Mon, Dec 16, 2019, 3:21 AM David Sidrane 
>> wrote:
>> 
>>> Brennan,
>>> 
>>> Thank you for your efforts!
>>> 
>>> Justin: Is there an issue with adding all the PPMC to have the 
>>> ability to edit the content?
>>> 
>>> I see some naming that looks like url id became the Page Title:
>>> 
>>> For example: NuttX Initialization Sequence is listed under 
>>> Initsequence
>>> 
>>> https://cwiki.apache.org/confluence/display/NUTTXTEST/Initsequence
>>> 
>>> Also is there a way to maintain the original authors?
>>> 
>>> David
>>> 
>>> -Original Message-
>>> From: Brennan Ashton [mailto:bash...@brennanashton.com]
>>> Sent: Sunday, December 15, 2019 11:16 PM
>>> To: dev@nuttx.apache.org
>>> Subject: Re: [nuttx] Wiki Backup
>>> 
>>> Ok,
>>> That was a bigger hassle than I expected.  The converter tool was 
>>> getting tripped up with odd escaping and generating bad XML files 
>>> for confluence, but I think it is good now.
>>> I also went through and manually cleaned the naming, obvious issues, 
>>> and inserted a bunch of confluence macros on the pages.
>>> 
>>> https://cwiki.apache.org/confluence/display/NUTTXTEST/Nuttx
>>> 
>>> I think it is good to go live, but there are a few things to address:
>>> 1) There are some links that were not wiki links, but url links to 
>>> the wiki that did not get converted.  I have the sources to find all 
>>> of these, so
>> I
>>> will tackle that soon.
>>> 2a) The documentation pages are embedding the HTML documentation 
>>> that is on nuttx.org/Documentation but once the code is moved to 
>>> github/apache I
>> will
>>> update to pull the latest.
>>> 2b) The documentation is using favicons internally as images, this 
>>> is not valid and causes issues broken image links.  This should be 
>>> fixed in the code no changes are needed on the wiki.
>>> 3) The presentations are linked to pdfs at nuttx.org Those PDFs 
>>> should just become attachments to wiki pages.
>>> 
>>> Justin if you move this to NUTTX from NUTTXTEST please add me to the 
>>> permissions on that space as well.
>>> 
>>> Thanks,
>>> Brennan
>>> 
>>> On Sun, Dec 15, 2019 at 4:27 PM Gregory Nutt 
>> wrote:
>>> 
 
> First stab at the import went surprisingly well.  All but a few 
> pages converted, unfortunately the hierarchy did not convert 
> correctly so I
 will
> have to mess with it more (these tools are mostly abandoned for 

Re: Wiki Backup

[Gregory Nutt]

Great work.  It looks great; and you made it look easy ;)


The bring-up was fast... but there were a few long nights I am sure.

When things are ready and stable, I will disable nutt.org and redirect 
that to the Apache Confluence website.  Just let me know when nuttx.org 
is no longer needed.  nuttx.com will also be be redirected.  Will that 
be at https://nuttx.incubator.apache.org/ like the status page or 
https://nuttx.apache.org/ like the email?

Re: patch for ntpclient: merge xmit and recv buffer into one to save the stack

[Nathan Hartman]

On Tue, Dec 17, 2019 at 11:40 AM Xiang Xiao  wrote:
> It seems that I can't attach the file to dev@nuttx.apache.org:(.
> My attachment in previous email also lose:
> https://lists.apache.org/thread.html/9bc6f92e39b9d2f401e1554c0e3270d574067ff608d13df1c1c1b11e%40
>
> Justin, can we send the attachment to dev@nuttx.apache.org?
>
> On Wed, Dec 18, 2019 at 12:17 AM Gregory Nutt  wrote:
> >
> >
> > > another patch  fix warning: 'g_nullstring' defined but not used.
> > I don't see anything attached.

Copying Justin on this...

It's a pretty major problem if we can't use attachments here because
much of the NuttX community contributes by patches.

Thanks,
Nathan

Re: Wiki Backup

[Justin Mclean]

Hi,

> When things are ready and stable, I will disable nutt.org and redirect that 
> to the Apache Confluence website.  Just let me know when nuttx.org is no 
> longer needed.  nuttx.com will also be be redirected.  Will that be at 
> https://nuttx.incubator.apache.org/ like the status page or 
> https://nuttx.apache.org/ like the email?

I’d just use https://nuttx.apache.org/ that way there no need to change it in 
the future, but at some point you may want to consider donating those domain 
names to the ASF.

Thanks,
Justin

Re: patch for ntpclient: merge xmit and recv buffer into one to save the stack

[Justin Mclean]

Hi,

> Justin, can we send the attachment to dev@nuttx.apache.org?

You can but it increases the chance the email will be marked as spam. I believe 
we can ask Infra to modify that.

Thanks,
Justin

Re: Wiki Backup

[David S. Alessio]

> On Dec 17, 2019, at 12:21 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> When things are ready and stable, I will disable nutt.org and redirect that 
>> to the Apache Confluence website.  Just let me know when nuttx.org is no 
>> longer needed.  nuttx.com will also be be redirected.  Will that be at 
>> https://nuttx.incubator.apache.org/ like the status page or 
>> https://nuttx.apache.org/ like the email?
> 
> I’d just use https://nuttx.apache.org/ that way there no need to change it in 
> the future, but at some point you may want to consider donating those domain 
> names to the ASF.

We need to somehow preserve the ownership of “nuttx.org”, I’d hate to see that 
domain hijacked and redirected to 

Regards,
-david

Re: Wiki Backup

[Gregory Nutt]

When things are ready and stable, I will disable nutt.org and redirect that to 
the Apache Confluence website.  Just let me know when nuttx.org is no longer 
needed.  nuttx.com will also be be redirected.  Will that be at 
https://nuttx.incubator.apache.org/ like the status page or 
https://nuttx.apache.org/ like the email?

I’d just use https://nuttx.apache.org/ that way there no need to change it in 
the future, but at some point you may want to consider donating those domain 
names to the ASF.


That would be fine... However, my personal email linked to many 
accounts, services, etc. is gn...@nuttx.org.  That would be a little 
awkward.  In the future, as you say, perhaps... unless my email would 
stay stable.


Greg

Re: Wiki Backup

[Gregory Nutt]

When things are ready and stable, I will disable nutt.org and redirect that to 
the Apache Confluence website.  Just let me know when nuttx.org is no longer 
needed.  nuttx.com will also be be redirected.  Will that be at 
https://nuttx.incubator.apache.org/ like the status page or 
https://nuttx.apache.org/ like the email?

I’d just use https://nuttx.apache.org/ that way there no need to change it in 
the future, but at some point you may want to consider donating those domain 
names to the ASF.

We need to somehow preserve the ownership of “nuttx.org”, I’d hate to see that domain 
hijacked and redirected to 


It will be awhile before anything happens.  I hold these domains and 
they are being used for other purposes as well.  I believe that I am 
supposed hand over trademarks and the like when we graduate.  That is 
the point of no return.  Up until that point everything is reversible 
(but I many have wrong; I am usually wrong when I try to recite Apache 
stuff).


whois says that GoDaddy.com is the registrar.  I vaguely recall paying 
extra for the anonymity thing.


Someone in China holds nuttx.net and nuttx.com.cn.  Someone in China 
also holds the trademarks on NUTT (I am trademarked!) and NUTX.

Re: Wiki Backup

[Justin Mclean]

Hi,

> That would be fine... However, my personal email linked to many accounts, 
> services, etc. is gn...@nuttx.org. 

I see that complicates things a little, but reduces the risk of a cyber 
squatter getting the name.

> That would be a little awkward.  In the future, as you say, perhaps... unless 
> my email would stay stable.

I’m sure Infra should sort that out for you.

Thanks,
Justin

Re: patch for ntpclient: merge xmit and recv buffer into one to save the stack

[Gregory Nutt]

Justin, can we send the attachment to dev@nuttx.apache.org?

You can but it increases the chance the email will be marked as spam. I believe 
we can ask Infra to modify that.


How do other projects accept patches?  If there is a more standard way, 
we should consider that.


Greg

Re: patch for ntpclient: merge xmit and recv buffer into one to save the stack

[Gregory Nutt]

Justin, can we send the attachment to dev@nuttx.apache.org?
You can but it increases the chance the email will be marked as spam. 
I believe we can ask Infra to modify that.


How do other projects accept patches?  If there is a more standard 
way, we should consider that. 


I find a lot of good information on the Apache Commons project pages:

   *Submitting A Patch. * Please use JIRA, patches sent to the mailing
   lists are harder to track and use up more bandwidth. 
   https://commons.apache.org/patches.html

We don't have have Jira set up, do we?  Should continue to take patches 
on the Google group until Jira is available.

Re: Wiki Backup

[Justin Mclean]

Hi,

> It will be awhile before anything happens.  I hold these domains and they are 
> being used for other purposes as well.  I believe that I am supposed hand 
> over trademarks and the like when we graduate.  That is the point of no 
> return.  Up until that point everything is reversible (but I many have wrong; 
> I am usually wrong when I try to recite Apache stuff).

That correct.

> Someone in China holds nuttx.net and nuttx.com.cn.  Someone in China also 
> holds the trademarks on NUTT (I am trademarked!) and NUTX.

This may be an issue down the track, we may want to speak to trademarks@ about 
this to see what can be sorted out or at least make them aware of a potential 
issue.

Thanks,
Justin

Re: patch for ntpclient: merge xmit and recv buffer into one to save the stack

[Justin Mclean]

Hi,

Other project use in no particular order:
- GitHub issues
- JIRA
- Mailing list
- Github PRs

Some (most?) accept multiple ways of submitting patches.

Thanks,
Justin

Repo transfers

[Justin Mclean]

Hi,

So the discussion on legal discuss has died down [1] and the SGA has been 
filled. My reading of that legal thread is that you now OK to transfer 
everything across. Code not owned by the Nuttx project can be worked as needed 
as everything is under a compatible license (BSD/MIT) and we have ICLAs (or 
will soon do) from the major contributors. Given bitbucket is git under the 
hood I’m not even sure we need to involve Infra and can just transfer the repos 
across and history will still be preserved.

I would suggest we ask for a VM from infra to set up fossology [2] so we can 
track all of the licenses / owners of the files. The will also help up build up 
the LICENSE (and NOTICE) files. This process will take time but it doesn’t have 
to be complete before you make you first release here and can happen in 
parallel.  One consideration may be that projects generally get one free VM and 
we may want to use it for something else. It may be that other project will 
want to use fossology and we get around it that way.

Does anyone has a different approach to suggest?

Thanks,
Justin

1. 
https://lists.apache.org/thread.html/d58f8edd36eff155f061e84229dc035a71ea5cd7f0fa622bdd1a5dd0%40%3Clegal-discuss.apache.org%3E
2. https://www.fossology.org

Re: Repo transfers

[Gregory Nutt]

Sounds good to me 8-)

On 12/17/2019 5:36 PM, Justin Mclean wrote:

Hi,

So the discussion on legal discuss has died down [1] and the SGA has been 
filled. My reading of that legal thread is that you now OK to transfer 
everything across. Code not owned by the Nuttx project can be worked as needed 
as everything is under a compatible license (BSD/MIT) and we have ICLAs (or 
will soon do) from the major contributors. Given bitbucket is git under the 
hood I’m not even sure we need to involve Infra and can just transfer the repos 
across and history will still be preserved.

I would suggest we ask for a VM from infra to set up fossology [2] so we can 
track all of the licenses / owners of the files. The will also help up build up 
the LICENSE (and NOTICE) files. This process will take time but it doesn’t have 
to be complete before you make you first release here and can happen in 
parallel.  One consideration may be that projects generally get one free VM and 
we may want to use it for something else. It may be that other project will 
want to use fossology and we get around it that way.

Does anyone has a different approach to suggest?

Thanks,
Justin

1. 
https://lists.apache.org/thread.html/d58f8edd36eff155f061e84229dc035a71ea5cd7f0fa622bdd1a5dd0%40%3Clegal-discuss.apache.org%3E
2. https://www.fossology.org

Apache Account Setup

[Gregory Nutt]

PPMC members have Apache email addresses.  Mine is gn...@apache.org for 
example.  I stumbled across this account configuration utility: 
https://id.apache.org/  You can use that to setup your forwarding 
address (and your github name) . I see some PPMC people already know 
this.  There is information here on how to setup gmail to send from your 
apache.org email using a gmail account.

Re: patch for ntpclient: merge xmit and recv buffer into one to save the stack

[Xiang Xiao]

Should we enable the attachment before the new workflow settle? so the
traditional workflow can transfer from google group to here
immediately.

Thanks
Xiang

On Wed, Dec 18, 2019 at 5:55 AM Justin Mclean  wrote:
>
> Hi,
>
> Other project use in no particular order:
> - GitHub issues
> - JIRA
> - Mailing list
> - Github PRs
>
> Some (most?) accept multiple ways of submitting patches.
>
> Thanks,
> Justin

Re: patch for ntpclient: merge xmit and recv buffer into one to save the stack

[Gregory Nutt]

Should we enable the attachment before the new workflow settle? so the
traditional workflow can transfer from google group to here
immediately.


There is no reason to send patches to any of the Apache resources now.  
They cannot be used there until the repositories are in place and we 
have at least a functional description of the workflow.  All patches 
will be applied to the Bitbucket repositories until that two things are 
in place.  I suggest that you continue to send patch to the Google group 
until then.


Greg

Re: Repo transfers

[Justin Mclean]

HI,

I think this can be done as simple as using these two commands, but I’ve not 
tried it before.
 git clone —mirror oldrepo
 git push —mirror newreeo

Here’s a slightly longer set of command which does the same. [1]

Worse case we can wipe the repo and ask again and/or ask Infra to franker it 
for us.

Thanks,
Justin

1. https://www.atlassian.com/git/tutorials/git-move-repository