Re: Hardware rendered Wayland client up and running

[K. Macy]

On Saturday, August 13, 2016, Adrian Chadd  wrote:

> w!
>
> ok, what has to be committed to -head?




O.o

For the range of hardware supported by 3.8 just evdev and his drm kevent
patch. For anything newer (e.g. Cherryview) everything in my patch queue
that we've been talking about for at least a month.



-a
>
>
> On 13 August 2016 at 19:12, Lundberg, Johannes
> > wrote:
> > Hi FreeBSD hackers!
> >
> > Today we reached a big milestone. For the first time, we could render
> > Wayland clients, backed by hardware, not shm (shared memory), on Intel
> Atom
> > Cherryview.
> >
> > Please see attached image of my setup.
> >
> > UP board (Intel Cherryview)
> > OS running on on-board eMMC (need sdhci and mmc patches to function)
> > Ports: https://github.com/freebsd/freebsd-ports-graphics/tree/wayland
> > Base: https://github.com/FreeBSDDesktop/freebsd-base-
> graphics/tree/drm-next
> > (from today, evdev enabled kernel)
> >
> > Mouse and keyboard available using libinput.
> > Device detection by libudev-devd.
> >
> > Only one thing, we needed to disable PRIME in drm to get the Wayland
> > clients to properly allocate image buffers. Working on getting that
> fixed!
> >
> > This opens up for the next big task, getting XWayland working that enable
> > use of unmodified X clients as well as testing Wayland enabled libraries
> > like Enlightenment, QT5, GTK3, etc. That however is not high priority for
> > me so I will probably not work on that.
> >
> > [image: Inline image 1]
> >
> > --
> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > 秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
> > もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
> > 複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
> > ---
> > CONFIDENTIALITY NOTE: The information in this email is confidential
> > and intended solely for the addressee.
> > Disclosure, copying, distribution or any other action of use of this
> > email by person other than intended recipient, is prohibited.
> > If you are not the intended recipient and have received this email in
> > error, please destroy the original message.
> > ___
> > freebsd-current@freebsd.org  mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
> freebsd-current-unsubscr...@freebsd.org "
> ___
> freebsd-current@freebsd.org  mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org
> "
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Enigmail issues in 11.0-RC1

[Davor Balder]

Hi all,

I am experiencing issues with Enigmail (version 1.9.4 (20160704-1534)
and Thunderbird 45.2.0). *
*

*Issue: *Error - encryption command failed. Despite the fact pinentry
gtk 2. pinentry-gnome3 and pinentry-ncurses are installed passphrase
dialogue does not come up.
Instead, the process exists with error. *
*

*Attempt to solve*

I am able to kill gpg agent and run the following:

gpg-agent --daemon --homedir=~/.gnupg  

However, when I do that I am able to enter passphrase *in terminal
window* (which is literal, not hidden for some reason). Password
dialogue does not come up. Passphrase in terminal window is not accepted
and the process exists with error (bad passphrase).

It would appear, at least in my case, that pinentry never kicks in to
offer a suitable dialog box.

I am not certain if this is a known problem with 11.0-BETA4 or 11.0-RC1.
I started playing with this a few days ago and I noticed this annoying
issue. I managed to get gpg to work OK with alpine and mutt but not with
enigmail.


Do we have a fix on the way at all?


-Davor

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Mosh regression between 10.x and 11-stable

[john hood]

On 8/13/16 4:30 AM, Peter Jeremy wrote:
> Hi John,
> 
> Sorry, I got side-tracked.
> 
> On 2016-Aug-12 16:37:15 -0400, John Hood  wrote:
>> >Could I ask you to look at this a little further?  On the one hand, it
>> >sure looks like a Mosh issue, and tcdrain() solves it-- but on the other
>> >hand, this is a regression on FreeBSD and we don't see this issue on any
>> >other OS.  I'd like to fully understand this and make sure that this is
>> >not a kernel issue.
> It's got me puzzled as well.  And it's only getting wierder...  The
> following is using an unmodified mosh-1.2.5, built from the port, as
> the server on FreeBSD 11.0-BETA4 r303957.  The client is 1.2.4a-1ubuntu1
> on Linux.  the standard driver script consistently fails but adding a
> "print" makes it mostly work.  Where there's a "[mosh is exiting.]"
> message, it was successful (and would report that there were other
> orphaned servers since I wasn't waiting the 60 seconds for servers to
> die between invocations).  For completeness, I've tried ktrace'ing
> mosh-server but can't make it fail when I do so.

I've now managed to reproduce the issue *and* ktrace it (and sshd) on a
VPS, with a single-CPU VM on a badly-oversubscribed VMWare host and OS X
client.

mosh-server shows a straightforward execution trace, the parent
successfully writes the MOSH CONNECT message on stdout, forks and exits.
 About a millisecond later, the child starts running, writes the verbose
copyright/etc. message on stderr, and gets EIO (and ignores it).
Shortly thereafter it closes its pty slave fds on stdin/stdout/stderr.
It continues normally from there.

In that millisecond, the sshd trace shows that it catches SIGCHLD,
writes utmp info, wait()s for a child and gets mosh-server's pid, and
does a final read() that returns 0 bytes.  It then closes the pty
master, without doing revoke() or any ioctls.

So the pty driver is clearly dropping the MOSH CONNECT message.  It's a
lot less clear whether that's a bug.  On the one hand,

states that output should be drained on final close (which in this case
is done by the forked mosh-server).  On the other hand, the login shell
is session leader, and

requires that the terminal be disassociated from the session when it exits.

I suspect that this problem is most visible on single-core machines,
because on a multi-core machine the pty driver, mosh-servers, and sshd
will run with different ordering, and I suspect that the mosh-server
child gets to close the pty slave before sshd closes the pty master.

I wrote a Xenix serial driver ages ago and I can see arguments for
either draining or dropping final output.  And Mosh's behavior is a
little questionable here.  So I'm not sure whether to call this a kernel
pty bug or not.  But the workaround in Mosh is easy enough, tcdrain(),
so I'm doing that anyway.

regards,

  --jh

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

compiling elf toolchain under gcc-5.3 mips

[Adrian Chadd]

hiya,

This seems to be needed for compiling elftoolchain under gcc-5.3
targeting mips (CROSS_TOOLCHAIN=mips-gcc) otherwise it complains that
sz isn't always initialised:

adrian@gertrude:~/work/freebsd/head-embedded/src % svn diff contrib
Index: contrib/elftoolchain/elfcopy/ascii.c
===
--- contrib/elftoolchain/elfcopy/ascii.c(revision 303837)
+++ contrib/elftoolchain/elfcopy/ascii.c(working copy)
@@ -251,6 +251,7 @@
sec_index = 1;
sec_addr = entry = 0;
while (fgets(line, _LINE_BUFSZ, ifp) != NULL) {
+   sz = 0; /* Quieten GCC-5.3 */
if (line[0] == '\r' || line[0] == '\n')
continue;
if (line[0] == '$' && line[1] == '$') {


Is that acceptable?



-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"