Like it. Thanks!

s/Firware/Firmware/

Nice to have feature, to allow to wait for required drivers to attach.

Check paddr for overflow.

Check paddr for overflow.

In D21272#462874, @kib wrote:

In D21272#462601, @markj wrote:

Can't we simply test paddr < rounddown2(seg->end, VM_LEVEL_0_SIZE)?

Is seg->end 0xffffffff or 0 for the problematic case ?

No, it is 0xfff00000. But problem with paddr, which is 32bits and paddr + 0x100000 will be 0x00000000.
It satisfy check:
0xffe00000 <= 0xfff00000 - true
0xfff00000 <= 0xfff00000 - true
0x00000000 <= 0xfff00000 - true

Or even (intmax_t), for this code not to make problems 10-20 years later :)

What about that version? :)

Simplify patch.

In D21272#462554, @markj wrote:

In D21272#462545, @ray wrote:

In D21272#462526, @markj wrote:

Don't we then have the same problem if seg->end < VM_LEVEL_0_SIZE?

only if you want to add some really small seg at 0x00000000 :)

Why does it have to be at 0x00000000? With the segment below we will test 0x100000 <= 0x9d000 - 0x100000, and the variables are unsigned.

SEGMENT 0:  
                                   
start:     0x10000                 
end:       0x9d000
domain:    0                       
free list: 0xffffffff81233cb0

In D21272#462526, @markj wrote:

Don't we then have the same problem if seg->end < VM_LEVEL_0_SIZE?

Remove extra parentheses.

Add Michal, to have one more test.

Thanks!

In D19266#412263, @kib wrote:

In D19266#412252, @ray wrote:

Looks fine!
Cosmetic: why not to name it just "xz" instead of "xz_embedded"?

Both module, module build directory, and linker file are named xz. What part name don't you like ?

Looks fine!
Cosmetic: why not to name it just "xz" instead of "xz_embedded"?

Looks good.
Thank you!

Looks cute :)

Correct. Thank you!

Sorry, I don't feel myself enough knowledgeable to give sane answer here :)

Looks good. Thanks.

style(9) issues still here (but in different functions), but there is a lot from very first vt project release.

Looks good. Thank you, Jonathan!

Thanks a lot, guys!

In D8749#181338, @yamori813_yahoo.co.jp wrote:

gpiobus_pin_setflags() in gpibus.c have check gpio_check_flags(). This code check pin capabirity. If low driver not support GPIO_PIN_PULLUP/GPIO_PIN_PULLDOWN return EINVAL.

Cool! Thank you Oleksandr!

Now, looks fine.

Now, looks fine.

I'm afraid JEDEC CFI standard do not allow simple omit of upper byte(s), you have to try bus and chip data width and get temporary configuration, til required data read from chip.

Only one comment left.

Looks good to me too. Thanks Stanislav.

I like it

In D1291#20, @royger wrote:

I'm not sure I'm following, AFAICT nexus doesn't know anything about the FB, how is it supposed to claim the memory regions?

In D1291#18, @emaste wrote:

In D1291#15, @ray wrote:

Possible, resource can be busy (by parent who setup FB), so if resource busy we have not to panic.

I think we can require the parent setting up the FB to alloc the resource, no?

I like it.
Good idea Roger. Thank you for that!

At least vt(4) currently less problematic than syscons(4) :-D

There is several ways:

1. You can change ABI, but not merge that changes to older releases.
2. Or keep ABI, and merge whatever you need

:-D

Looks fine.
But I did not able to test it :) (at least now)

Yup, that one looks correct.

Thanks Ed!

That is what I have to done while ago :)
One comment - there is last `kbdd_ioctl(...KDSKBMODE...) in the vtterm_cngetc, so looks like grab/ungrab have to save/restore kbdstate of current window too. (I'm not sure)

Looks good.

Committed 271464, 271465, 271466.

Fix stray char on paste.

Copy data only on BUTTON-UP events.

Committed as r271381.
Thank you guys!

btw, anybody know where to get scancodes without making experiments? :)

Lets look it from other point of view:
o Implement all special combinations that syscons(4) have.
o Point to kbdmap(5) for reference.

Guys,
how is it looks now? :)

o Extend descriptions for reboot and debug.
o Use RB_AUTOBOOT.

Looks good!

Looks good!

Agree, too.
Save world using less electric power :)

Yeah, it is right thing.
Please do!

In D568#5, @emaste wrote:

Actually it's an endianness issue, which I did not notice until r269783 went in
http://svnweb.freebsd.org/changeset/base/269783

It's actually an ARGB little-endian framebuffer, or BGRA when viewed as big-endian data.

canonical source:

inline u_int32_t
fb_colour(int r, int g, int b)
{
  return ((r&0xff)<<8) | ((g&0xff)<<16) | ((b&0xff)<<24);
}

Patch looks good to me (only OF_getpropenc to look).

Looks good to me.