Clipboard synchronization between Chromium OS and guest OS #144

Merged
merged 31 commits into from Dec 10, 2013

Conversation

Projects
None yet
9 participants
@drinkcat
Collaborator

drinkcat commented May 11, 2013

Here is my attempt at solving the clipboard synchronization problem:

  • I created a simple Chromium OS application. It listens on TCP port 30001: If the input from the connection starts with a P, it copy the rest of the data in the clipboard; If not, it outputs the content of the clipboard. It uses a dirty trick to update the clipboard (copy the text in a textarea, select it, then call the copy or paste command): I looked around, and it seems like it's the only way to do it...
  • On the guest OS, xclip is used to fetch and update the clipboard content.
  • ratpoison contains a new hook, that calls a script called croutonclip. That script figures out the current and next window, and copies the clipboard content as necessary.

There are still a few FIXME in the code. In particular, I am concerned about the dependency on netcat.

I'm not sure how easy it is to review the code with github, since this branch contains a number of incremental commits. If you want I can squash them in logical units.

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid May 11, 2013

Owner

Squashed commits are somewhat cleaner, but this form is still easy to review thanks to the "files" tab on Github which displays the cumulative changes.

Several comments:

  1. This is pretty awesome. Good work coming up with this!
  2. Is it possible to make the extension work by adding an icon at the top rather than opening a tab?
  3. I'm not familiar with Javascript, but just to confirm, the extension only accepts connections from the local machine?
  4. Is it possible to programmatically install the extension?
  5. Tapping into Ratpoison will only work with the Xephyr target, which is only installed by default on ARM. I don't think you need to do that though. Instead, couldn't you monitor the Chromium clipboard with the extension, monitor for chroot X11 selection changes with xprop or something, and keep open a persistent nc connection between the two, sharing things as they change?
Owner

dnschneid commented May 11, 2013

Squashed commits are somewhat cleaner, but this form is still easy to review thanks to the "files" tab on Github which displays the cumulative changes.

Several comments:

  1. This is pretty awesome. Good work coming up with this!
  2. Is it possible to make the extension work by adding an icon at the top rather than opening a tab?
  3. I'm not familiar with Javascript, but just to confirm, the extension only accepts connections from the local machine?
  4. Is it possible to programmatically install the extension?
  5. Tapping into Ratpoison will only work with the Xephyr target, which is only installed by default on ARM. I don't think you need to do that though. Instead, couldn't you monitor the Chromium clipboard with the extension, monitor for chroot X11 selection changes with xprop or something, and keep open a persistent nc connection between the two, sharing things as they change?
@drinkcat

This comment has been minimized.

Show comment
Hide comment
@drinkcat

drinkcat May 12, 2013

Collaborator
  1. Thanks ,-) As a disclaimer, my knowledge of Javascript is also very limited, so I hope I didn't write something awfully ugly ,-)

  2. I tried, this was my first approach actually (building a Chrome extension rather than an application). Unfortunately, when I add the socket permission to the extension, I get 'socket' is only allowed for packaged apps, and this is a extension.... So you cannot create raw sockets with an extension it seems...

    Then, I tried to hide the window: extensions can have "background" pages that are not displayed to the user. It seems like applications do not have that facility, though...

  3. Yes. We are binding on 127.0.0.1. Confirmed with netstat -ant:

Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 127.0.0.1:30001         0.0.0.0:*               LISTEN    
  1. That'd be nice. No idea. I'll have a look.
  2. Well, the problem here is that I don't see a way to monitor the Chromium clipboard (no doubt it can be done on the X side)... There is no proper API in Chromium to do that currently (I copy-paste from an HTML textarea in this code...). Could we monitor for VT change instead? VT_WAITACTIVE in http://linux.die.net/man/4/console_ioctl may do the trick...
Collaborator

drinkcat commented May 12, 2013

  1. Thanks ,-) As a disclaimer, my knowledge of Javascript is also very limited, so I hope I didn't write something awfully ugly ,-)

  2. I tried, this was my first approach actually (building a Chrome extension rather than an application). Unfortunately, when I add the socket permission to the extension, I get 'socket' is only allowed for packaged apps, and this is a extension.... So you cannot create raw sockets with an extension it seems...

    Then, I tried to hide the window: extensions can have "background" pages that are not displayed to the user. It seems like applications do not have that facility, though...

  3. Yes. We are binding on 127.0.0.1. Confirmed with netstat -ant:

Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 127.0.0.1:30001         0.0.0.0:*               LISTEN    
  1. That'd be nice. No idea. I'll have a look.
  2. Well, the problem here is that I don't see a way to monitor the Chromium clipboard (no doubt it can be done on the X side)... There is no proper API in Chromium to do that currently (I copy-paste from an HTML textarea in this code...). Could we monitor for VT change instead? VT_WAITACTIVE in http://linux.die.net/man/4/console_ioctl may do the trick...
@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid May 12, 2013

Owner

2: Can extensions read files? Maybe you could make a set of fifos (mkfifo) and have the extension read and write them to communicate with the chroots (via bind mounts).

5: That would probably work fine for the chromium side. For the X11 side, I still recommend monitoring for selection changes, so that copy -> quit chroot -> Chromium OS paste still works.

Owner

dnschneid commented May 12, 2013

2: Can extensions read files? Maybe you could make a set of fifos (mkfifo) and have the extension read and write them to communicate with the chroots (via bind mounts).

5: That would probably work fine for the chromium side. For the X11 side, I still recommend monitoring for selection changes, so that copy -> quit chroot -> Chromium OS paste still works.

@drinkcat

This comment has been minimized.

Show comment
Hide comment
@drinkcat

drinkcat May 12, 2013

Collaborator

2: Well, the 'fileSystem' permission is not allowed with extensions, so, same problem...

5: I'm not sure if we want to constantly synchronize the clipboard, as this may cause some overhead, and would make the code more complicated to avoid issues like having 2 chroots bouncing the content off each other in an infinite loop... (The VNC viewer also behaves that way: it copies the content when the mouse enters/exits the window).

For the issue you mention, we could add something in xserverrc, so that the content is transferred back to Chrome just before the X11 server is terminated. Something like: X/Xephyr ... "$@; croutonclip --some-option" should do the trick... (EDIT: No. It should be somewhere in xinit I guess: can we put a wrapper around the WM-provided xinitrc to execute something after the wm is closed?)

Another note, what I synchronize here is the X11 "clipboard" (the one that is accessed by Ctrl-C/V), not the X11 "primary" (selection + middle button). The main reason is that there is no way to click the middle button in the chroot with the trackpad, so the "primary" clipboard is not so useful anyway (or am I missing something?).

It thought of copying from "primary" if not empty, otherwise from "clipboard". But from Chromium->guest, where should we paste? Both?

Collaborator

drinkcat commented May 12, 2013

2: Well, the 'fileSystem' permission is not allowed with extensions, so, same problem...

5: I'm not sure if we want to constantly synchronize the clipboard, as this may cause some overhead, and would make the code more complicated to avoid issues like having 2 chroots bouncing the content off each other in an infinite loop... (The VNC viewer also behaves that way: it copies the content when the mouse enters/exits the window).

For the issue you mention, we could add something in xserverrc, so that the content is transferred back to Chrome just before the X11 server is terminated. Something like: X/Xephyr ... "$@; croutonclip --some-option" should do the trick... (EDIT: No. It should be somewhere in xinit I guess: can we put a wrapper around the WM-provided xinitrc to execute something after the wm is closed?)

Another note, what I synchronize here is the X11 "clipboard" (the one that is accessed by Ctrl-C/V), not the X11 "primary" (selection + middle button). The main reason is that there is no way to click the middle button in the chroot with the trackpad, so the "primary" clipboard is not so useful anyway (or am I missing something?).

It thought of copying from "primary" if not empty, otherwise from "clipboard". But from Chromium->guest, where should we paste? Both?

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid May 14, 2013

Owner

2: Yikes. Unfortunately I'm not well-versed in extensions and packaged apps, so I can't really give you a good pointer. What would be ideal is if we could drop that entirely and get a dbus interface to the clipboard. I'll ask someone about that.

5: The issue is that the more you branch out in configs, the less of a chance everything works in all situations. The clipboard doesn't change so often that I'd be worried about overhead, and it avoids the issue of reacting to the X server quitting entirely.

Definitely sync the "clipboard" selection both ways, not touching primary. Chromium OS doesn't have a primary selection, so to be consistent, it should sync with "clipboard" on the X11 side. Selecting other text should definitely not wipe out the Chromium OS clipboard; that's not very intuitive.

Owner

dnschneid commented May 14, 2013

2: Yikes. Unfortunately I'm not well-versed in extensions and packaged apps, so I can't really give you a good pointer. What would be ideal is if we could drop that entirely and get a dbus interface to the clipboard. I'll ask someone about that.

5: The issue is that the more you branch out in configs, the less of a chance everything works in all situations. The clipboard doesn't change so often that I'd be worried about overhead, and it avoids the issue of reacting to the X server quitting entirely.

Definitely sync the "clipboard" selection both ways, not touching primary. Chromium OS doesn't have a primary selection, so to be consistent, it should sync with "clipboard" on the X11 side. Selecting other text should definitely not wipe out the Chromium OS clipboard; that's not very intuitive.

@drinkcat

This comment has been minimized.

Show comment
Hide comment
@drinkcat

drinkcat May 14, 2013

Collaborator

2: Completely agree. If we can get something cleaner, and that can be used with a "vanilla" Chrome OS, that would be awesome.

5: Alright. So, I looked a bit more into the inner workings of the X11 clipboard, and well, it's complicated... There does not seem to be an easy way to monitor clipboard content changes (the reason being that in X11, the original app owns the content until it is pasted), at least, nothing that can be put together with a few bash commands.

It seems there is a lot of interest in clipboard sharing for remote desktop and virtual machines, but no one has implemented a generic solution. Things I looked at at either very complex, and maybe not very clean (synergy, seems to handle MIME types and stuff), or very simple (vncviewer: copy/paste content on mouse enter/exit).

This paper gives a good summary (http://pvanhoof.be/files/Problems%20of%20the%20X11%20clipboard.pdf):

It's nearly impossible to make the clipboard shared across different desktop computers. In fact it is
possible, but such an implementation would be needlessly difficult and complex.

The same can be said of support for virtualization (Qemu, Xen, VMWare). Sharing the clipboard
between a virtual machine and the desktop itself is painfully difficult to implement correctly (in
case X11 is running on the host operating system). Virtual machines are becoming important
aspects of desktop computing.

Do you see any other issue with the current way (copy on window switch)? The current code is so simple that I'm not sure if we want to implement something so much more complicated...

I just commited some code that will copy the clipboard before the X server exits (basically, we change window just before the server exits, so that the content is copied)...

Collaborator

drinkcat commented May 14, 2013

2: Completely agree. If we can get something cleaner, and that can be used with a "vanilla" Chrome OS, that would be awesome.

5: Alright. So, I looked a bit more into the inner workings of the X11 clipboard, and well, it's complicated... There does not seem to be an easy way to monitor clipboard content changes (the reason being that in X11, the original app owns the content until it is pasted), at least, nothing that can be put together with a few bash commands.

It seems there is a lot of interest in clipboard sharing for remote desktop and virtual machines, but no one has implemented a generic solution. Things I looked at at either very complex, and maybe not very clean (synergy, seems to handle MIME types and stuff), or very simple (vncviewer: copy/paste content on mouse enter/exit).

This paper gives a good summary (http://pvanhoof.be/files/Problems%20of%20the%20X11%20clipboard.pdf):

It's nearly impossible to make the clipboard shared across different desktop computers. In fact it is
possible, but such an implementation would be needlessly difficult and complex.

The same can be said of support for virtualization (Qemu, Xen, VMWare). Sharing the clipboard
between a virtual machine and the desktop itself is painfully difficult to implement correctly (in
case X11 is running on the host operating system). Virtual machines are becoming important
aspects of desktop computing.

Do you see any other issue with the current way (copy on window switch)? The current code is so simple that I'm not sure if we want to implement something so much more complicated...

I just commited some code that will copy the clipboard before the X server exits (basically, we change window just before the server exits, so that the content is copied)...

@tedm

This comment has been minimized.

Show comment
Hide comment
@tedm

tedm May 14, 2013

Contributor

I hope you are successful with this, it looks like a great utility.

What I've been using to copy data between the chroots is evernote, which is
installed in chrome/chromium in both environments. But if there is just a
snippet of data or url I'd like to copy, then paste after hot-keying, I
don't have a quick and fast way to do that yet.

With virtualbox, it has always been convenient to minimize a guest os, and
use the host os's copy/paste features, treating the windowed guest as a app
for that purpose.

another useful thing I've found, but could be unreliable, is that stdout
often directs to a crosh shell that launched the chroot, and I keep shared
data that I want to access between host, chroot, and new chroots in
~/Downloads/data/xxx so it persists across chroot deletes and re-installs.
symlinks there work well.

Look forward to testing your project when it is built.

On Tue, May 14, 2013 at 5:24 AM, drinkcat notifications@github.com wrote:

2: Completely agree. If we can get something cleaner, and that can be used
with a "vanilla" Chrome OS, that would be awesome.

5: Alright. So, I looked a bit more into the inner workings of the X11
clipboard, and well, it's complicated... There does not seem to be an easy
way to monitor clipboard content changes (the reason being that in X11, the
original app owns the content until it is pasted), at least, nothing that
can be put together with a few bash commands.

It seems there is a lot of interest in clipboard sharing for remote
desktop and virtual machines, but no one has implemented a generic
solution. Things I looked at at either very complex, and maybe not very
clean (synergy http://synergy-foss.org/, seems to handle MIME types and
stuff), or very simple (vncviewer http://tightvnc.com/vncviewer.1.html:
copy/paste content on mouse enter/exit).

This paper gives a good summary (
http://pvanhoof.be/files/Problems%20of%20the%20X11%20clipboard.pdf):

It's nearly impossible to make the clipboard shared across different desktop computers. In fact it is
possible, but such an implementation would be needlessly difficult and complex.

The same can be said of support for virtualization (Qemu, Xen, VMWare). Sharing the clipboard
between a virtual machine and the desktop itself is painfully difficult to implement correctly (in
case X11 is running on the host operating system). Virtual machines are becoming important
aspects of desktop computing.

Do you see any other issue with the current way (copy on window switch)?
The current code is so simple that I'm not sure if we want to implement
something so much more complicated...

I just commited some code that will copy the clipboard before the X server
exits (basically, we change window just before the server exits, so that
the content is copied)...


Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/pull/144#issuecomment-17872512
.

Contributor

tedm commented May 14, 2013

I hope you are successful with this, it looks like a great utility.

What I've been using to copy data between the chroots is evernote, which is
installed in chrome/chromium in both environments. But if there is just a
snippet of data or url I'd like to copy, then paste after hot-keying, I
don't have a quick and fast way to do that yet.

With virtualbox, it has always been convenient to minimize a guest os, and
use the host os's copy/paste features, treating the windowed guest as a app
for that purpose.

another useful thing I've found, but could be unreliable, is that stdout
often directs to a crosh shell that launched the chroot, and I keep shared
data that I want to access between host, chroot, and new chroots in
~/Downloads/data/xxx so it persists across chroot deletes and re-installs.
symlinks there work well.

Look forward to testing your project when it is built.

On Tue, May 14, 2013 at 5:24 AM, drinkcat notifications@github.com wrote:

2: Completely agree. If we can get something cleaner, and that can be used
with a "vanilla" Chrome OS, that would be awesome.

5: Alright. So, I looked a bit more into the inner workings of the X11
clipboard, and well, it's complicated... There does not seem to be an easy
way to monitor clipboard content changes (the reason being that in X11, the
original app owns the content until it is pasted), at least, nothing that
can be put together with a few bash commands.

It seems there is a lot of interest in clipboard sharing for remote
desktop and virtual machines, but no one has implemented a generic
solution. Things I looked at at either very complex, and maybe not very
clean (synergy http://synergy-foss.org/, seems to handle MIME types and
stuff), or very simple (vncviewer http://tightvnc.com/vncviewer.1.html:
copy/paste content on mouse enter/exit).

This paper gives a good summary (
http://pvanhoof.be/files/Problems%20of%20the%20X11%20clipboard.pdf):

It's nearly impossible to make the clipboard shared across different desktop computers. In fact it is
possible, but such an implementation would be needlessly difficult and complex.

The same can be said of support for virtualization (Qemu, Xen, VMWare). Sharing the clipboard
between a virtual machine and the desktop itself is painfully difficult to implement correctly (in
case X11 is running on the host operating system). Virtual machines are becoming important
aspects of desktop computing.

Do you see any other issue with the current way (copy on window switch)?
The current code is so simple that I'm not sure if we want to implement
something so much more complicated...

I just commited some code that will copy the clipboard before the X server
exits (basically, we change window just before the server exits, so that
the content is copied)...


Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/pull/144#issuecomment-17872512
.

@appsforartists

This comment has been minimized.

Show comment
Hide comment
@appsforartists

appsforartists May 30, 2013

How generic is this solution? There are many situations where communicating between the two systems would be beneficial. For example, it would be useful if crouton could tell if the ChromeOS lock screen is (or should be) up, and to run xlock when it is. Also, it could listen for links clicked in crouton and open new Chrome tabs for them.

How generic is this solution? There are many situations where communicating between the two systems would be beneficial. For example, it would be useful if crouton could tell if the ChromeOS lock screen is (or should be) up, and to run xlock when it is. Also, it could listen for links clicked in crouton and open new Chrome tabs for them.

@drinkcat

This comment has been minimized.

Show comment
Hide comment
@drinkcat

drinkcat May 31, 2013

Collaborator

@appsforartists: Thanks for the comment. Indeed, there are many things that this app could do: what you mention, but also installing/updating chroots, for example. It's just that the clipboard thing was the most needed for me, so that's what I implemented first, but yes, I'll look into extending it.

Collaborator

drinkcat commented May 31, 2013

@appsforartists: Thanks for the comment. Indeed, there are many things that this app could do: what you mention, but also installing/updating chroots, for example. It's just that the clipboard thing was the most needed for me, so that's what I implemented first, but yes, I'll look into extending it.

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid May 31, 2013

Owner

Still looking into some way of directly hooking into Chromium OS for the clipboard.
Other features could be more simply implemented with shell scripts, as soon as someone figures out the magic to launch a new Chromium OS tab from the shell (it's harder than it appears; see #147).

Owner

dnschneid commented May 31, 2013

Still looking into some way of directly hooking into Chromium OS for the clipboard.
Other features could be more simply implemented with shell scripts, as soon as someone figures out the magic to launch a new Chromium OS tab from the shell (it's harder than it appears; see #147).

@tedm

This comment has been minimized.

Show comment
Hide comment
@tedm

tedm May 31, 2013

Contributor

I have a related feature request for an even simpler than mentioned copy/clipboard between chroot and chromos:

Previously I suggested somehow being able to run the same browser, or have the same browser settings between chroot and Chrome, and that was shot down. Of course the Chrome browser is faster and more full featured than Chromium and probably Chrome in linux.

However, the reason I end up using Chromium in the chroot is because I often have a URL link I need to paste, and have nowhere to quickly copy it to before I can hot-key to Chromeos, so I end up in Chromium. (Evernote open in both browsers can work, but is slow, especially if not already opened tabs in both chroot and chromeos).

Could copied text in a chroot, short (e.g. < 256 bytes or so) be written to a file in ~/Downloads/buffer.txt and then read and pasted into a chromeos extension icon (or new tab) after switch from chroot to chromeos?

Contributor

tedm commented May 31, 2013

I have a related feature request for an even simpler than mentioned copy/clipboard between chroot and chromos:

Previously I suggested somehow being able to run the same browser, or have the same browser settings between chroot and Chrome, and that was shot down. Of course the Chrome browser is faster and more full featured than Chromium and probably Chrome in linux.

However, the reason I end up using Chromium in the chroot is because I often have a URL link I need to paste, and have nowhere to quickly copy it to before I can hot-key to Chromeos, so I end up in Chromium. (Evernote open in both browsers can work, but is slow, especially if not already opened tabs in both chroot and chromeos).

Could copied text in a chroot, short (e.g. < 256 bytes or so) be written to a file in ~/Downloads/buffer.txt and then read and pasted into a chromeos extension icon (or new tab) after switch from chroot to chromeos?

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid May 31, 2013

Owner

How is that any different from clipboard synchronization?
A separate feature that would be nice would be a url handler that tosses the URL to the Chromium OS session and switches automatically. That belongs in a separate issue though, which you're welcome to create.

Owner

dnschneid commented May 31, 2013

How is that any different from clipboard synchronization?
A separate feature that would be nice would be a url handler that tosses the URL to the Chromium OS session and switches automatically. That belongs in a separate issue though, which you're welcome to create.

@tedm

This comment has been minimized.

Show comment
Hide comment
@tedm

tedm May 31, 2013

Contributor

Yes, the URL handler to ChromeOS is what I'd like.

I'l leave the implementation to the programmers, but when I saw the use of TCP ports to be used, and needing a command line way to open up a tab, I thought (possibly naively) that the method I described could avoid those two tough areas that I don't wouldn't know where to begin coding. I have done the extension tutorial with about 5 lines of code that gets flickr cat images, with an icon, so I was thinking if on the chroot side, the copy could be written to file, then on the chromeos side, no need to find a magic command line to new tab function, just change get flickr cat code lines to grab url from file and paste in omnibox. I will write up URL handler feature request.

Contributor

tedm commented May 31, 2013

Yes, the URL handler to ChromeOS is what I'd like.

I'l leave the implementation to the programmers, but when I saw the use of TCP ports to be used, and needing a command line way to open up a tab, I thought (possibly naively) that the method I described could avoid those two tough areas that I don't wouldn't know where to begin coding. I have done the extension tutorial with about 5 lines of code that gets flickr cat images, with an icon, so I was thinking if on the chroot side, the copy could be written to file, then on the chromeos side, no need to find a magic command line to new tab function, just change get flickr cat code lines to grab url from file and paste in omnibox. I will write up URL handler feature request.

@tedm tedm referenced this pull request May 31, 2013

Closed

feature request - URL handler #186

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid Jun 13, 2013

Owner

Star this bug if you're interested, but no need to comment on it.

Owner

dnschneid commented Jun 13, 2013

Star this bug if you're interested, but no need to comment on it.

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid Jul 21, 2013

Owner

@drinkcat, you wouldn't happen to have played with creating a websockets server in the chroot so that the sync app can be made into an extension? It's looking like we may end up being forced to have some kind of crouton extension to enable both clipboard sync and URL handling, and it'd be nice to have it as an extension rather than a packaged app.

Owner

dnschneid commented Jul 21, 2013

@drinkcat, you wouldn't happen to have played with creating a websockets server in the chroot so that the sync app can be made into an extension? It's looking like we may end up being forced to have some kind of crouton extension to enable both clipboard sync and URL handling, and it'd be nice to have it as an extension rather than a packaged app.

@drinkcat

This comment has been minimized.

Show comment
Hide comment
@drinkcat

drinkcat Jul 22, 2013

Collaborator

Yes. That seems to be the way. Did a quick and dirty test, and I can access the clipboard, and open a websocket to a localhost server. I will start implementing.

Collaborator

drinkcat commented Jul 22, 2013

Yes. That seems to be the way. Did a quick and dirty test, and I can access the clipboard, and open a websocket to a localhost server. I will start implementing.

@drinkcat

This comment has been minimized.

Show comment
Hide comment
@drinkcat

drinkcat Jul 25, 2013

Collaborator

I have a first implementation working in 168acc7. Wrote a wiki page that documents the protocol.

Maybe if you have some feedback before I start cleaning up the code.

Collaborator

drinkcat commented Jul 25, 2013

I have a first implementation working in 168acc7. Wrote a wiki page that documents the protocol.

Maybe if you have some feedback before I start cleaning up the code.

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid Jul 25, 2013

Owner

That looks really well thought-out. Nice!
Are you using EOFs to mark the end of FIFO transactions? That's pretty clever. I was going to comment that adding the length of the buffer in shell is actually pretty trivial (${#var} to calculate the length, read to grab the command and length if line-separated, and head -c to grab the right length), but I think the EOF approach is more robust against failures, especially since websockets has arbitrary frame sizes to match.

Go ahead and clean this up; I'll provide some general comments inline.

Owner

dnschneid commented Jul 25, 2013

That looks really well thought-out. Nice!
Are you using EOFs to mark the end of FIFO transactions? That's pretty clever. I was going to comment that adding the length of the buffer in shell is actually pretty trivial (${#var} to calculate the length, read to grab the command and length if line-separated, and head -c to grab the right length), but I think the EOF approach is more robust against failures, especially since websockets has arbitrary frame sizes to match.

Go ahead and clean this up; I'll provide some general comments inline.

@drinkcat

This comment has been minimized.

Show comment
Hide comment
@drinkcat

drinkcat Jul 26, 2013

Collaborator

Are you using EOFs to mark the end of FIFO transactions?

Yes. And by using 2 pipes, where every command is acknowledged, we make sure that 2 consecutive commands do not get concatenated by accident.

I was going to comment that adding the length of the buffer in shell is actually pretty trivial [...]

Noted ,-) (Getting the write buffer length might be trickier, especially if you do not want me to create a temporary file)

Collaborator

drinkcat commented Jul 26, 2013

Are you using EOFs to mark the end of FIFO transactions?

Yes. And by using 2 pipes, where every command is acknowledged, we make sure that 2 consecutive commands do not get concatenated by accident.

I was going to comment that adding the length of the buffer in shell is actually pretty trivial [...]

Noted ,-) (Getting the write buffer length might be trickier, especially if you do not want me to create a temporary file)

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid Jul 29, 2013

Owner

I wonder if it's possible to programmatically install the extension by doing something like the following (totally untested):

  1. Bind-mount /opt/google/chrome/extensions to a temporary directory in /var/run/
  2. Mount a tmpfs over /opt/google/chrome/extensions
  3. Symlink managed_users and *.crx into the tmpfs mount (so far this is the same thing that enter-chroot does with /usr/bin when running from an sd card)
  4. Copy the crouton.crx into the tmpfs mount
  5. Copy external_extensions.json from the bind mount into the tmpfs mount, adding a crouton.crx entry.
  6. Wait for user confirmation then kill the chrome browser process to force it to reload the extensions (or maybe it responds to signals or something to check external extensions again?)
  7. Wait for the extension to appear (or be updated) in ~/Extensions, then unmount the bind and tmpfs.

This may not persist across reboots if Chromium OS uninstalls the extension when it sees the external_extensions.crx entry removed.

Alternatively, can the extension be manually unpacked into the ~/Extensions directory and chrome restarted to pick it up?

Owner

dnschneid commented Jul 29, 2013

I wonder if it's possible to programmatically install the extension by doing something like the following (totally untested):

  1. Bind-mount /opt/google/chrome/extensions to a temporary directory in /var/run/
  2. Mount a tmpfs over /opt/google/chrome/extensions
  3. Symlink managed_users and *.crx into the tmpfs mount (so far this is the same thing that enter-chroot does with /usr/bin when running from an sd card)
  4. Copy the crouton.crx into the tmpfs mount
  5. Copy external_extensions.json from the bind mount into the tmpfs mount, adding a crouton.crx entry.
  6. Wait for user confirmation then kill the chrome browser process to force it to reload the extensions (or maybe it responds to signals or something to check external extensions again?)
  7. Wait for the extension to appear (or be updated) in ~/Extensions, then unmount the bind and tmpfs.

This may not persist across reboots if Chromium OS uninstalls the extension when it sees the external_extensions.crx entry removed.

Alternatively, can the extension be manually unpacked into the ~/Extensions directory and chrome restarted to pick it up?

@drinkcat

This comment has been minimized.

Show comment
Hide comment
@drinkcat

drinkcat Aug 1, 2013

Collaborator

Alright, I squashed the commits into logical units for easier review. I haven't tried installing the extension automagically yet, but that doesn't change anything to the rest of the code.

Some notes:

  • We only support plain text clipboard data. Rich text will be converted to plain text in xclip or the Chromium extension. To make sure that we don't erase rich text by accident, we always compare the current clipboard content. E.g. if you have rich text copied in crouton, you will see it as plain text in Chromium OS, but it will still be rich text in crouton no matter now matter how many times you switch display.
  • Binary data (e.g. selection from Gimp) requires special handling, as it appears as an empty string when copied by xclip, and I have not found a way to put an empty string in the clipboard in Chromium (there are ways with a Flash(!) plugin: I refuse to go that way ,-)). For this case, we paste <crouton-empty-Y3JvdXRvbgo=> to the Chromium clipboard, and if we read back the same string, we just pretend that the clipboard content is empty. (this still allows users to copy-paste <crouton-empty-Y3JvdXRvbgo=> if they really want to, provided that they don't: copy binary data (or an empty string) in crouton, switch to Chromium OS, copy the text, then go back to crouton). (and yes I became a fan of base64 strings since reading WebSocket's RFC ,-))
  • Clipboard is lost when the X server quits. I can't think of a way around this. Remember, in X11, the application owns the clipboard: When the application quits, the clipboard is lost. Most DE have something called a clipboard manager that claims the clipboard for this case. The problem is that, once the DE exits, the clipboard manager also exits, and we have no way of getting the clipboard content from the latter part of croutonxinitrc-wrapper. We could write our own clipboard manager, but I'm not sure how to make it interact correctly with the one present in DEs.

Known bug:

  • There is be a problem in the following scenario: Start chroot 1, start chroot 2, then quit chroot 1. I understand that CROUTON="CORE is meant for this purpose, but I can't get it to work: unmount-chroot keeps looping at Sending SIGKILL. Actually, when starting/stopping crouton multiple times, pressing Ctrl-C at weird moments (and scripts failing because of mistakes in my code), I sometimes also have that problem because of croutonwheel.

I will put a few more comments attached to the commits.

Collaborator

drinkcat commented Aug 1, 2013

Alright, I squashed the commits into logical units for easier review. I haven't tried installing the extension automagically yet, but that doesn't change anything to the rest of the code.

Some notes:

  • We only support plain text clipboard data. Rich text will be converted to plain text in xclip or the Chromium extension. To make sure that we don't erase rich text by accident, we always compare the current clipboard content. E.g. if you have rich text copied in crouton, you will see it as plain text in Chromium OS, but it will still be rich text in crouton no matter now matter how many times you switch display.
  • Binary data (e.g. selection from Gimp) requires special handling, as it appears as an empty string when copied by xclip, and I have not found a way to put an empty string in the clipboard in Chromium (there are ways with a Flash(!) plugin: I refuse to go that way ,-)). For this case, we paste <crouton-empty-Y3JvdXRvbgo=> to the Chromium clipboard, and if we read back the same string, we just pretend that the clipboard content is empty. (this still allows users to copy-paste <crouton-empty-Y3JvdXRvbgo=> if they really want to, provided that they don't: copy binary data (or an empty string) in crouton, switch to Chromium OS, copy the text, then go back to crouton). (and yes I became a fan of base64 strings since reading WebSocket's RFC ,-))
  • Clipboard is lost when the X server quits. I can't think of a way around this. Remember, in X11, the application owns the clipboard: When the application quits, the clipboard is lost. Most DE have something called a clipboard manager that claims the clipboard for this case. The problem is that, once the DE exits, the clipboard manager also exits, and we have no way of getting the clipboard content from the latter part of croutonxinitrc-wrapper. We could write our own clipboard manager, but I'm not sure how to make it interact correctly with the one present in DEs.

Known bug:

  • There is be a problem in the following scenario: Start chroot 1, start chroot 2, then quit chroot 1. I understand that CROUTON="CORE is meant for this purpose, but I can't get it to work: unmount-chroot keeps looping at Sending SIGKILL. Actually, when starting/stopping crouton multiple times, pressing Ctrl-C at weird moments (and scripts failing because of mistakes in my code), I sometimes also have that problem because of croutonwheel.

I will put a few more comments attached to the commits.

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid Aug 2, 2013

Owner

Oh man, this is awesome.

Owner

dnschneid commented Aug 2, 2013

Oh man, this is awesome.

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid Aug 2, 2013

Owner

Why not just not sync empty clipboards? I don't see the benefit.

Owner

dnschneid commented Aug 2, 2013

Why not just not sync empty clipboards? I don't see the benefit.

@drinkcat

This comment has been minimized.

Show comment
Hide comment
@drinkcat

drinkcat Aug 2, 2013

Collaborator

Oh man, this is awesome.

,-)

Why not just not sync empty clipboards? I don't see the benefit.

Because I can't "copy" an empty selection in Chromium... The way the extension works is just like you would do it by hand (write text in a textarea, select it all, press "Ctrl-C")... If you do not have text, you cannot select it. When you press Ctrl-C without a selection, nothing happens, the clipboard still stays the same...

Apparently Chromium has no better interface to access the clipboard, that would allow to do clipboard=""...

Collaborator

drinkcat commented Aug 2, 2013

Oh man, this is awesome.

,-)

Why not just not sync empty clipboards? I don't see the benefit.

Because I can't "copy" an empty selection in Chromium... The way the extension works is just like you would do it by hand (write text in a textarea, select it all, press "Ctrl-C")... If you do not have text, you cannot select it. When you press Ctrl-C without a selection, nothing happens, the clipboard still stays the same...

Apparently Chromium has no better interface to access the clipboard, that would allow to do clipboard=""...

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid Aug 2, 2013

Owner

How about just leaving the clipboards desynced instead of clearing them all? Same goes in the opposite direction.

Owner

dnschneid commented Aug 2, 2013

How about just leaving the clipboards desynced instead of clearing them all? Same goes in the opposite direction.

@drinkcat

This comment has been minimized.

Show comment
Hide comment
@drinkcat

drinkcat Aug 2, 2013

Collaborator

Well, that's an option, we could leave the clipboard desynced, and only resync when the content changes (remember, we cannot detect if the user copies some text: we can only compare content).

I thought about it, but it leaves a problem in the following scenario:

  1. In cros: User selects "Hello", presses Ctrl-C, then switches to crouton. (clipboard content: cros="Hello", crouton="Hello")
  2. In crouton, user does some work, and copies part of an image (binary data). (cros="Hello", crouton="")
  3. Then the user switches back to cros. (The crouton extension detects an empty clipboard, so it does not erase the content, and remembers the current content ("Hello"). cros="Hello", crouton="")
  4. The user sees "Hello" selected, and that's exactly what he needs! (yeah, in 2., he got distracted by the image, and forgot that he wanted to do something with "Hello"). He presses Ctrl-C.
  5. Then he switches to crouton. The extension thinks that nothing has changed, so it does not sync the clipboard (cros="Hello", crouton="").
  6. The user pastes in crouton, and gets an image instead of "Hello"...

I think it's fairly realistic (I could totally imagine falling into that), and recovering synchronization would be tricky: the user would need to copy some random text before it syncs again... Far more confusing than getting some <crouton-empty-blabla> if you paste something you were not supposed to paste. Actually, we could make that dummy string longer with some clearer information about what is going on, maybe even with a link to a wiki page here that explains the problem...

Erasing the content in 5. is also not an option. Imagine you're following a Gimp tutorial in cros, you would constantly switch between cros and crouton to read the next step. Having your image in the clipboard erased everytime you do a switch would be a real pain.

Overall, I agree, this is a hack, but this is the least worst solution I could come up with...

Collaborator

drinkcat commented Aug 2, 2013

Well, that's an option, we could leave the clipboard desynced, and only resync when the content changes (remember, we cannot detect if the user copies some text: we can only compare content).

I thought about it, but it leaves a problem in the following scenario:

  1. In cros: User selects "Hello", presses Ctrl-C, then switches to crouton. (clipboard content: cros="Hello", crouton="Hello")
  2. In crouton, user does some work, and copies part of an image (binary data). (cros="Hello", crouton="")
  3. Then the user switches back to cros. (The crouton extension detects an empty clipboard, so it does not erase the content, and remembers the current content ("Hello"). cros="Hello", crouton="")
  4. The user sees "Hello" selected, and that's exactly what he needs! (yeah, in 2., he got distracted by the image, and forgot that he wanted to do something with "Hello"). He presses Ctrl-C.
  5. Then he switches to crouton. The extension thinks that nothing has changed, so it does not sync the clipboard (cros="Hello", crouton="").
  6. The user pastes in crouton, and gets an image instead of "Hello"...

I think it's fairly realistic (I could totally imagine falling into that), and recovering synchronization would be tricky: the user would need to copy some random text before it syncs again... Far more confusing than getting some <crouton-empty-blabla> if you paste something you were not supposed to paste. Actually, we could make that dummy string longer with some clearer information about what is going on, maybe even with a link to a wiki page here that explains the problem...

Erasing the content in 5. is also not an option. Imagine you're following a Gimp tutorial in cros, you would constantly switch between cros and crouton to read the next step. Having your image in the clipboard erased everytime you do a switch would be a real pain.

Overall, I agree, this is a hack, but this is the least worst solution I could come up with...

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid Aug 2, 2013

Owner

Gotcha. One last possibility: instead of , what about a single character like a space, period, or asterisk?

Owner

dnschneid commented Aug 2, 2013

Gotcha. One last possibility: instead of , what about a single character like a space, period, or asterisk?

@drinkcat

This comment has been minimized.

Show comment
Hide comment
@drinkcat

drinkcat Aug 2, 2013

Collaborator

That makes sense. I think I'll use "%", it's a common character (it should be on every keyboard so no one should need to copy-paste it), yet big enough so you can clearly see that you pasted it (you may miss a space or a small symbol like ".").

(my initial reaction was, what if the user really wants to copy that character? Came up with this: some guy with a broken keyboard can't type "%", so he searches for "percent" on Wikipedia, puts it in the clipboard as a workaround, AND happened to copy some binary data in crouton just before that. But that does not seem too likely ,-)).

Collaborator

drinkcat commented Aug 2, 2013

That makes sense. I think I'll use "%", it's a common character (it should be on every keyboard so no one should need to copy-paste it), yet big enough so you can clearly see that you pasted it (you may miss a space or a small symbol like ".").

(my initial reaction was, what if the user really wants to copy that character? Came up with this: some guy with a broken keyboard can't type "%", so he searches for "percent" on Wikipedia, puts it in the clipboard as a workaround, AND happened to copy some binary data in crouton just before that. But that does not seem too likely ,-)).

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid Aug 2, 2013

Owner

Poor guy won't be able to write the number 5, either.

Owner

dnschneid commented Aug 2, 2013

Poor guy won't be able to write the number 5, either.

chroot-bin/croutonclip
+
+# Write a command to croutonwebsocket, and read back response
+websocketcommand() {
+ # Check that $PIPEDIR and the FIFO pipes exist

This comment has been minimized.

@dnschneid

dnschneid Aug 3, 2013

Owner

indentation

@dnschneid

dnschneid Aug 3, 2013

Owner

indentation

chroot-bin/croutonclip
+cliptmp2="`mktemp "croutonclip.XXX" --tmpdir=/tmp`"
+
+TRAP="rm -f '$cliptmp' '$cliptmp2'; exit 2"
+trap "$TRAP" INT TERM HUP 0

This comment has been minimized.

@dnschneid

dnschneid Aug 3, 2013

Owner

Having "exit 2" in the trap for 0 will cause the script to always return 2.
See installer/functions:settrap.
Any reason TERM is in there? I believe it's covered by 0 (ditto down below)

Anyway, as mentioned below, it's probably worth importing the common functions.

@dnschneid

dnschneid Aug 3, 2013

Owner

Having "exit 2" in the trap for 0 will cause the script to always return 2.
See installer/functions:settrap.
Any reason TERM is in there? I believe it's covered by 0 (ditto down below)

Anyway, as mentioned below, it's probably worth importing the common functions.

This comment has been minimized.

@drinkcat

drinkcat Aug 4, 2013

Collaborator

Oh yeah silly me... Fell in the same "trap" 2 months ago while fixing those functions ,-)

Imported the functions (I was under the impression I couldn't, but I can). And TERM is indeed not needed.

@drinkcat

drinkcat Aug 4, 2013

Collaborator

Oh yeah silly me... Fell in the same "trap" 2 months ago while fixing those functions ,-)

Imported the functions (I was under the impression I couldn't, but I can). And TERM is indeed not needed.

This comment has been minimized.

@drinkcat

drinkcat Aug 4, 2013

Collaborator

Well, TERM handling is not that simple, try this:

. installer/functions
addtrap "echo EXIT"
sh -c "sleep 2; echo Killing; kill -s TERM $$" &
while [ 1 ]; do echo -n .; sleep 1; done

In both bash and dash, signals HUP & INT wait for the current command to complete, then run the handler as expected. In bash & dash, TERM aborts the current command, but the EXIT trap is only run in bash (dash just exits).

Because of that, the trap is never executed, and croutonwebsocket is left running (orphaned). So we need to trap TERM to avoid this problem.

We can do it by default in functions (is that a problem for other scripts?), or add a variable EXTRASIG with a list of extra signals to trap.

@drinkcat

drinkcat Aug 4, 2013

Collaborator

Well, TERM handling is not that simple, try this:

. installer/functions
addtrap "echo EXIT"
sh -c "sleep 2; echo Killing; kill -s TERM $$" &
while [ 1 ]; do echo -n .; sleep 1; done

In both bash and dash, signals HUP & INT wait for the current command to complete, then run the handler as expected. In bash & dash, TERM aborts the current command, but the EXIT trap is only run in bash (dash just exits).

Because of that, the trap is never executed, and croutonwebsocket is left running (orphaned). So we need to trap TERM to avoid this problem.

We can do it by default in functions (is that a problem for other scripts?), or add a variable EXTRASIG with a list of extra signals to trap.

This comment has been minimized.

@drinkcat

drinkcat Aug 4, 2013

Collaborator

EDIT: Forget it, it works...

Spoke too fast... This is a headache... Adding a trap on TERM breaks this:

    {
        host-x11 xev -root &
        addtrap "kill $!"
        wait
    }

Since the trap won't get executed until wait returns, and wait may only return once the trap is executed...

@drinkcat

drinkcat Aug 4, 2013

Collaborator

EDIT: Forget it, it works...

Spoke too fast... This is a headache... Adding a trap on TERM breaks this:

    {
        host-x11 xev -root &
        addtrap "kill $!"
        wait
    }

Since the trap won't get executed until wait returns, and wait may only return once the trap is executed...

This comment has been minimized.

@dnschneid

dnschneid Aug 4, 2013

Owner

Yeah, adding TERM to settrap is fine.

@dnschneid

dnschneid Aug 4, 2013

Owner

Yeah, adding TERM to settrap is fine.

chroot-bin/croutonclip
+ return 0
+ fi
+
+ if [ "$current" = "$next" ]; then

This comment has been minimized.

@dnschneid

dnschneid Aug 3, 2013

Owner

"${current:="$next"}"

would get rid of the previous if block as well. You can also combine that with the first if block.

@dnschneid

dnschneid Aug 3, 2013

Owner

"${current:="$next"}"

would get rid of the previous if block as well. You can also combine that with the first if block.

chroot-bin/croutonclip
+ [ -n "$VERBOSE" ] && echo ">>Current: $current>>"
+
+ # Copy clipboard content from the current display
+ if [ "$current" = ':0' ]; then

This comment has been minimized.

@dnschneid

dnschneid Aug 3, 2013

Owner

I'd like to limit the temporary file usage. The way to avoid most temporary file usage would be to do something like this (untested; comments/debug/error prints omitted for brevity):

{
    if [ "$current" = ':0' ]; then
        echo -n 'R' | websocketcommand
    else
        echo -n 'R'
        DISPLAY="$current" xclip -o -sel clip
    fi
} | (
    STATUS="`head -c 1`"
    if [ "$STATUS" != 'R' ]; then
        exit 0
    fi
    if [ "$next" = ':0' ]; then
        STATUS="`(echo -n 'W'; cat) | websocketcommand`"
        if [ "$STATUS" != 'WOK' ]; then
            exit 1
        fi
    else
        tmpfile="`mktemp`"
        trap "rm -f '$tmpfile'" 0
        cat > "$tmpfile"
        if ! DISPLAY="$next" xclip -o -sel clip | diff -q - "$tmpfile" >/dev/null; then
            DISPLAY="$next" xclip -i -sel clip "$tmpfile"
        fi
    fi
) && current="$next"

Can't think of a way to not need a temporary file for the second one.

@dnschneid

dnschneid Aug 3, 2013

Owner

I'd like to limit the temporary file usage. The way to avoid most temporary file usage would be to do something like this (untested; comments/debug/error prints omitted for brevity):

{
    if [ "$current" = ':0' ]; then
        echo -n 'R' | websocketcommand
    else
        echo -n 'R'
        DISPLAY="$current" xclip -o -sel clip
    fi
} | (
    STATUS="`head -c 1`"
    if [ "$STATUS" != 'R' ]; then
        exit 0
    fi
    if [ "$next" = ':0' ]; then
        STATUS="`(echo -n 'W'; cat) | websocketcommand`"
        if [ "$STATUS" != 'WOK' ]; then
            exit 1
        fi
    else
        tmpfile="`mktemp`"
        trap "rm -f '$tmpfile'" 0
        cat > "$tmpfile"
        if ! DISPLAY="$next" xclip -o -sel clip | diff -q - "$tmpfile" >/dev/null; then
            DISPLAY="$next" xclip -i -sel clip "$tmpfile"
        fi
    fi
) && current="$next"

Can't think of a way to not need a temporary file for the second one.

This comment has been minimized.

@drinkcat

drinkcat Aug 4, 2013

Collaborator

Maybe we can hack something with tee... Will try later.

@drinkcat

drinkcat Aug 4, 2013

Collaborator

Maybe we can hack something with tee... Will try later.

This comment has been minimized.

@dnschneid

dnschneid Aug 4, 2013

Owner

I tried this for a while and got a headache. Pretty sure that even if it is possible, you risk blocking the pipes if the output gets too long.

@dnschneid

dnschneid Aug 4, 2013

Owner

I tried this for a while and got a headache. Pretty sure that even if it is possible, you risk blocking the pipes if the output gets too long.

This comment has been minimized.

@drinkcat

drinkcat Aug 5, 2013

Collaborator

Ouch, I think I found a solution, but it hurts my eyes:

next=":0"

# Random data for testing
dd if=/dev/urandom | base64 | dd bs=1024 count=1000 > data 2>/dev/null

cat data | (
    rm tmp tmp2
    mkfifo tmp tmp2

    cat tmp | dd bs=16M iflag=fullblock count=1 | (
        if ! DISPLAY="$next" xclip -o -sel clip | diff -q - tmp2 > /dev/null; then
            echo diff
            cat | DISPLAY="$next" xclip -i -sel clip
        else
            echo same
        fi
    ) &
    cpid=$!

    tee tmp | dd bs=16M iflag=fullblock count=1 > tmp2

    wait $cpid
)

# Check if content identical
DISPLAY="$next" xclip -o -sel clip | diff -q -s - data

We always allocate 2*16MB of memory, and don't support clipboard larger than 16MB (croutonwebsocket won't accept more, anyway...).

We might be better off writing a small C wrapper around xclip... Or give up and use a temp file, which is not that bad to start with...

@drinkcat

drinkcat Aug 5, 2013

Collaborator

Ouch, I think I found a solution, but it hurts my eyes:

next=":0"

# Random data for testing
dd if=/dev/urandom | base64 | dd bs=1024 count=1000 > data 2>/dev/null

cat data | (
    rm tmp tmp2
    mkfifo tmp tmp2

    cat tmp | dd bs=16M iflag=fullblock count=1 | (
        if ! DISPLAY="$next" xclip -o -sel clip | diff -q - tmp2 > /dev/null; then
            echo diff
            cat | DISPLAY="$next" xclip -i -sel clip
        else
            echo same
        fi
    ) &
    cpid=$!

    tee tmp | dd bs=16M iflag=fullblock count=1 > tmp2

    wait $cpid
)

# Check if content identical
DISPLAY="$next" xclip -o -sel clip | diff -q -s - data

We always allocate 2*16MB of memory, and don't support clipboard larger than 16MB (croutonwebsocket won't accept more, anyway...).

We might be better off writing a small C wrapper around xclip... Or give up and use a temp file, which is not that bad to start with...

This comment has been minimized.

@dnschneid

dnschneid Aug 5, 2013

Owner

Yikes. Temp file it is :)

@dnschneid

dnschneid Aug 5, 2013

Owner

Yikes. Temp file it is :)

chroot-bin/croutonclip
+ [ -n "$VERBOSE" ] && echo "Ping..."
+
+ # Prepare and send a random ping message
+ RND="`head -c 9 /dev/urandom | base64`"

This comment has been minimized.

@dnschneid

dnschneid Aug 3, 2013

Owner

Why?

This comment has been minimized.

@drinkcat

drinkcat Aug 4, 2013

Collaborator

My idea was to make sure that we don't get a response from another ping (like, if a read from pipeout was interrupted in another process, or something around those lines, or if there is another croutonclip running)...

But yeah, this is overkill, and actually not protecting us against anything, if we have another croutonclip process this will eventually succeed anyway, and we would be then in big trouble...

I'll just send PING$timeout, good enough.

@drinkcat

drinkcat Aug 4, 2013

Collaborator

My idea was to make sure that we don't get a response from another ping (like, if a read from pipeout was interrupted in another process, or something around those lines, or if there is another croutonclip running)...

But yeah, this is overkill, and actually not protecting us against anything, if we have another croutonclip process this will eventually succeed anyway, and we would be then in big trouble...

I'll just send PING$timeout, good enough.

This comment has been minimized.

@dnschneid

dnschneid Aug 4, 2013

Owner

PING$$$timeout should make it as unique as we care about

@dnschneid

dnschneid Aug 4, 2013

Owner

PING$$$timeout should make it as unique as we care about

chroot-bin/croutonclip
+}
+
+croutonwebsocket &
+TRAP="kill $! 2> /dev/null; $TRAP"

This comment has been minimized.

@dnschneid

dnschneid Aug 3, 2013

Owner

It would probably be worth it for the script to source the common functions to get the addtrap/settrap stuff:
. "$BINDIR/../installer/functions"

@dnschneid

dnschneid Aug 3, 2013

Owner

It would probably be worth it for the script to source the common functions to get the addtrap/settrap stuff:
. "$BINDIR/../installer/functions"

chroot-bin/croutonclip
+# This makes sure we do not miss any events and that we copy the clipboard
+# around in the right sequence.
+
+# Launch xbindkeys for the Chromium OS X server if it isn't running

This comment has been minimized.

@dnschneid

dnschneid Aug 3, 2013

Owner

This comment seems misplaced

@dnschneid

dnschneid Aug 3, 2013

Owner

This comment seems misplaced

chroot-bin/croutonclip
+ m = ""
+ }
+ /^MapNotify/ {
+ m = $1

This comment has been minimized.

@dnschneid

dnschneid Aug 3, 2013

Owner

just set it to 1 since you don't need the value

@dnschneid

dnschneid Aug 3, 2013

Owner

just set it to 1 since you don't need the value

@drinkcat

This comment has been minimized.

Show comment
Hide comment
@drinkcat

drinkcat Nov 16, 2013

Collaborator

Did some more systematic testing on precise, saucy, wheezy, on a Samsung ARM (stable 4537.147.0). Uncovered a few bugs and potential issues, fixed in the last 5 commits above.

Testing methodology can be found here: https://gist.github.com/drinkcat/7469311 (what would be a proper place for this?).

Untested on x86/64, that needs to be done, since there is a separate code path for X11 (vs Xephyr on ARM).

Limitations, difficult to solve:

  • The extension only tries to connect every 5 seconds, so on chroot startup, the clipboard content from Chromium OS may only be available after 5 seconds at most.
  • The clipboard content is lost upon exiting a chroot. But this is more a limitation of the X11 protocol: the application holds the clipboard content, and the content is lost when the application closes. DE provide a clipboard manager for this purpose. But since the clipboard manager exists with the DE, that does not solve our problem...

Bugs/things to improve:

  1. croutonurlhandler does not work without a X server (since croutonclip is not started), and does not fail with a clear message: it waits forever.
  2. In case 8, if precise is stopped before precise.bis, crouton fails to detect that precise should still be mounted to keep croutonclip alive, tries to unmount the chroot, then tries to send TERM and KILL to process, but never terminates because croutonclip is launched with CROUTON=CORE. I believe this also affects croutonwheel.
  3. @kiko's patch still missing: I don't want to add new features until we get this merged.

Let me know if you think those are blockers, or if we can go ahead and fix later (I don't think they will affect the majority of users).

Collaborator

drinkcat commented Nov 16, 2013

Did some more systematic testing on precise, saucy, wheezy, on a Samsung ARM (stable 4537.147.0). Uncovered a few bugs and potential issues, fixed in the last 5 commits above.

Testing methodology can be found here: https://gist.github.com/drinkcat/7469311 (what would be a proper place for this?).

Untested on x86/64, that needs to be done, since there is a separate code path for X11 (vs Xephyr on ARM).

Limitations, difficult to solve:

  • The extension only tries to connect every 5 seconds, so on chroot startup, the clipboard content from Chromium OS may only be available after 5 seconds at most.
  • The clipboard content is lost upon exiting a chroot. But this is more a limitation of the X11 protocol: the application holds the clipboard content, and the content is lost when the application closes. DE provide a clipboard manager for this purpose. But since the clipboard manager exists with the DE, that does not solve our problem...

Bugs/things to improve:

  1. croutonurlhandler does not work without a X server (since croutonclip is not started), and does not fail with a clear message: it waits forever.
  2. In case 8, if precise is stopped before precise.bis, crouton fails to detect that precise should still be mounted to keep croutonclip alive, tries to unmount the chroot, then tries to send TERM and KILL to process, but never terminates because croutonclip is launched with CROUTON=CORE. I believe this also affects croutonwheel.
  3. @kiko's patch still missing: I don't want to add new features until we get this merged.

Let me know if you think those are blockers, or if we can go ahead and fix later (I don't think they will affect the majority of users).

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid Nov 18, 2013

Why so frequently?

Why so frequently?

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid Nov 18, 2013

Oh, whoops. Rate limiting. Disregard that.

Oh, whoops. Rate limiting. Disregard that.

This comment has been minimized.

Show comment
Hide comment
@drinkcat

drinkcat Nov 18, 2013

Owner

Yeah the previous version was doing that every 5 seconds ,-) And Chromium was rate-limiting it anyway (but not a lot, maybe limiting to one check every 10 seconds or so).

With this, if the extension is not connected, it will check every 15'. When connected for more than 15', it will check on disconnect. It's arbitrary, but I think it's reasonable.

Owner

drinkcat replied Nov 18, 2013

Yeah the previous version was doing that every 5 seconds ,-) And Chromium was rate-limiting it anyway (but not a lot, maybe limiting to one check every 10 seconds or so).

With this, if the extension is not connected, it will check every 15'. When connected for more than 15', it will check on disconnect. It's arbitrary, but I think it's reasonable.

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid Dec 4, 2013

Owner

Okay, check out the extension branch; I think it's in a merge-able state, assuming tests pass. I polished some things up (see the commits), and the extension no longer runs on non-Chromium OS, although I couldn't get it to hide the icon entirely. Please test it out (sorry, only @drinkcat has access to the webstore link right now) and make sure it still works.

In addition to the fixes needed in your comment, some other things I'd like to add:

  1. Use chrome.commands to implement the croutoncycle hotkey instead of the additional xbindkeys daemon. The daemon can still be conditionally launched if the extension is not present. We'll have to confirm if Ctrl+Alt+Shift+F1/F2 can actually be captured this way.
  2. The extension popup should enumerate the running graphical chroots, and clicking one should switch to it. This may require doing something creative with X11 root properties, as croutonwebsocket is run as an unprivileged user and will not be able to access /proc/*/root/etc/crouton/name.
  3. Double-clicking the extension popup should effectively croutoncycle next.
Owner

dnschneid commented Dec 4, 2013

Okay, check out the extension branch; I think it's in a merge-able state, assuming tests pass. I polished some things up (see the commits), and the extension no longer runs on non-Chromium OS, although I couldn't get it to hide the icon entirely. Please test it out (sorry, only @drinkcat has access to the webstore link right now) and make sure it still works.

In addition to the fixes needed in your comment, some other things I'd like to add:

  1. Use chrome.commands to implement the croutoncycle hotkey instead of the additional xbindkeys daemon. The daemon can still be conditionally launched if the extension is not present. We'll have to confirm if Ctrl+Alt+Shift+F1/F2 can actually be captured this way.
  2. The extension popup should enumerate the running graphical chroots, and clicking one should switch to it. This may require doing something creative with X11 root properties, as croutonwebsocket is run as an unprivileged user and will not be able to access /proc/*/root/etc/crouton/name.
  3. Double-clicking the extension popup should effectively croutoncycle next.
@DennisLfromGA

This comment has been minimized.

Show comment
Hide comment
@DennisLfromGA

DennisLfromGA Dec 4, 2013

Collaborator

Can't wait for the merge :)

This is a slightly pertinent possibly but I've got a little script that I
run in both crosh and my chroots that reports what tty/gui sessions are
running - it's here - https://gist.github.com/DennisLfromGA/7649026
I've also modded the croutoncycle to include the 'cros' @drinkcat addition
plus some for switching directly to a specific live tty/gui chroot that I
use in both crosh and my chroots - it's here -
https://gist.github.com/DennisLfromGA/7648913

I don't know if these are at all interesting or valuable to y'all but I
like'em...

On Wed, Dec 4, 2013 at 2:30 AM, David Schneider notifications@github.comwrote:

Okay, check out the extension branch; I think it's in a merge-able state,
assuming tests pass. I polished some things up (see the commits), and the
extension no longer runs on non-Chromium OS, although I couldn't get it to
hide the icon entirely. Please test it out (sorry, only @drinkcathttps://github.com/drinkcathas access to the webstore link right now) and make sure it still works.

In addition to the fixes needed in your commenthttps://github.com/dnschneid/crouton/pull/144#issuecomment-28628316,
some other things I'd like to add:

  1. Use chrome.commands to implement the croutoncycle hotkey instead of the
    additional xbindkeys daemon. The daemon can still be conditionally launched
    if the extension is not present. We'll have to confirm if
    Ctrl+Alt+Shift+F1/F2 can actually be captured this way.
  2. The extension popup should enumerate the running graphical chroots, and
    clicking one should switch to it. This may require doing something creative
    with X11 root properties, as croutonwebsocket is run as an unprivileged
    user and will not be able to access /proc/*/root/etc/crouton/name.
  3. Double-clicking the extension popup should effectively croutoncycle
    next.


Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/pull/144#issuecomment-29784818
.

DennyL@GMail

Collaborator

DennisLfromGA commented Dec 4, 2013

Can't wait for the merge :)

This is a slightly pertinent possibly but I've got a little script that I
run in both crosh and my chroots that reports what tty/gui sessions are
running - it's here - https://gist.github.com/DennisLfromGA/7649026
I've also modded the croutoncycle to include the 'cros' @drinkcat addition
plus some for switching directly to a specific live tty/gui chroot that I
use in both crosh and my chroots - it's here -
https://gist.github.com/DennisLfromGA/7648913

I don't know if these are at all interesting or valuable to y'all but I
like'em...

On Wed, Dec 4, 2013 at 2:30 AM, David Schneider notifications@github.comwrote:

Okay, check out the extension branch; I think it's in a merge-able state,
assuming tests pass. I polished some things up (see the commits), and the
extension no longer runs on non-Chromium OS, although I couldn't get it to
hide the icon entirely. Please test it out (sorry, only @drinkcathttps://github.com/drinkcathas access to the webstore link right now) and make sure it still works.

In addition to the fixes needed in your commenthttps://github.com/dnschneid/crouton/pull/144#issuecomment-28628316,
some other things I'd like to add:

  1. Use chrome.commands to implement the croutoncycle hotkey instead of the
    additional xbindkeys daemon. The daemon can still be conditionally launched
    if the extension is not present. We'll have to confirm if
    Ctrl+Alt+Shift+F1/F2 can actually be captured this way.
  2. The extension popup should enumerate the running graphical chroots, and
    clicking one should switch to it. This may require doing something creative
    with X11 root properties, as croutonwebsocket is run as an unprivileged
    user and will not be able to access /proc/*/root/etc/crouton/name.
  3. Double-clicking the extension popup should effectively croutoncycle
    next.


Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/pull/144#issuecomment-29784818
.

DennyL@GMail

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid Dec 5, 2013

Owner

Thanks for sharing that. The proper solution requires a bit more of a rewrite of some of the tools involved; I've started a smartcycle branch for that.

Owner

dnschneid commented Dec 5, 2013

Thanks for sharing that. The proper solution requires a bit more of a rewrite of some of the tools involved; I've started a smartcycle branch for that.

@DennisLfromGA

This comment has been minimized.

Show comment
Hide comment
@DennisLfromGA

DennisLfromGA Dec 5, 2013

Collaborator

Man-oh-man, your croutoncycle is very much improved! 👍 Hopefully it'll be installed in both the chroot-bin and the host-bin - very useful.

Collaborator

DennisLfromGA commented Dec 5, 2013

Man-oh-man, your croutoncycle is very much improved! 👍 Hopefully it'll be installed in both the chroot-bin and the host-bin - very useful.

@drinkcat

This comment has been minimized.

Show comment
Hide comment
@drinkcat

drinkcat Dec 8, 2013

Collaborator

@dnschneid : Did some simple tests, the extension branch looks fine (just posted 2 minor comments in 2b08fe3).

Collaborator

drinkcat commented Dec 8, 2013

@dnschneid : Did some simple tests, the extension branch looks fine (just posted 2 minor comments in 2b08fe3).

@dnschneid dnschneid merged commit 3662f3d into dnschneid:master Dec 10, 2013

@drinkcat

This comment has been minimized.

Show comment
Hide comment
@drinkcat

drinkcat Dec 10, 2013

Collaborator

7 months and countless comments & commits, we got it merged ,-) Party time!

Collaborator

drinkcat commented Dec 10, 2013

7 months and countless comments & commits, we got it merged ,-) Party time!

@drinkcat drinkcat deleted the drinkcat:clipboard branch Dec 10, 2013

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid Dec 10, 2013

Owner

That took an embarrassingly long time. Sorry about that!

Owner

dnschneid commented Dec 10, 2013

That took an embarrassingly long time. Sorry about that!

@DennisLfromGA

This comment has been minimized.

Show comment
Hide comment
@DennisLfromGA

DennisLfromGA Dec 10, 2013

Collaborator

Congrats guys! This is a big deal...

Collaborator

DennisLfromGA commented Dec 10, 2013

Congrats guys! This is a big deal...

@DennisLfromGA

This comment has been minimized.

Show comment
Hide comment
@DennisLfromGA

DennisLfromGA Dec 10, 2013

Collaborator

Just installed 'extension' on my Acer C710 quantal/gnome and it works
great! Thanx.
( sorry for getting a little over zealous in that last post :)

On Mon, Dec 9, 2013 at 10:35 PM, David Schneider
notifications@github.comwrote:

That took an embarrassingly long time. Sorry about that!


Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/pull/144#issuecomment-30196886
.

DennyL@GMail

Collaborator

DennisLfromGA commented Dec 10, 2013

Just installed 'extension' on my Acer C710 quantal/gnome and it works
great! Thanx.
( sorry for getting a little over zealous in that last post :)

On Mon, Dec 9, 2013 at 10:35 PM, David Schneider
notifications@github.comwrote:

That took an embarrassingly long time. Sorry about that!


Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/pull/144#issuecomment-30196886
.

DennyL@GMail

@DennisLfromGA

This comment has been minimized.

Show comment
Hide comment
@DennisLfromGA

DennisLfromGA Dec 10, 2013

Collaborator

I just attempted to add the new 'extension' target to my precise
chroot and it failed. I don't know if it was the target that made it fail
or if it was some other unrelated problem. I recorded the output
herehttp://pastebin.com/Q4QQMMgV for
your perusal. The strange thing is 'croutonversion' reports 'unknown' for
everything except the host version ??? It seems like it may be having
trouble determining between 32-bit & 64-bit but I'm not sure.

Any help or input would be appreciated.
-DennisL

P.S. I added the 'extension' target to my quantal & raring chroots without
a hitch so this is new to me...

On Mon, Dec 9, 2013 at 11:39 PM, Denny Lockhart denny.lockhart@gmail.comwrote:

Just installed 'extension' on my Acer C710 quantal/gnome and it works
great! Thanx.
( sorry for getting a little over zealous in that last post :)

On Mon, Dec 9, 2013 at 10:35 PM, David Schneider <notifications@github.com

wrote:

That took an embarrassingly long time. Sorry about that!


Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/pull/144#issuecomment-30196886
.

DennyL@GMail

DennyL@GMail

Collaborator

DennisLfromGA commented Dec 10, 2013

I just attempted to add the new 'extension' target to my precise
chroot and it failed. I don't know if it was the target that made it fail
or if it was some other unrelated problem. I recorded the output
herehttp://pastebin.com/Q4QQMMgV for
your perusal. The strange thing is 'croutonversion' reports 'unknown' for
everything except the host version ??? It seems like it may be having
trouble determining between 32-bit & 64-bit but I'm not sure.

Any help or input would be appreciated.
-DennisL

P.S. I added the 'extension' target to my quantal & raring chroots without
a hitch so this is new to me...

On Mon, Dec 9, 2013 at 11:39 PM, Denny Lockhart denny.lockhart@gmail.comwrote:

Just installed 'extension' on my Acer C710 quantal/gnome and it works
great! Thanx.
( sorry for getting a little over zealous in that last post :)

On Mon, Dec 9, 2013 at 10:35 PM, David Schneider <notifications@github.com

wrote:

That took an embarrassingly long time. Sorry about that!


Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/pull/144#issuecomment-30196886
.

DennyL@GMail

DennyL@GMail

@dnschneid

This comment has been minimized.

Show comment
Hide comment
@dnschneid

dnschneid Dec 10, 2013

Owner

@DennisLfromGA: try entering the chroot, saying "n" to finishing the update, then running sudo dpkg -r libsbc1 libsbc1:i386, exit the chroot, enter it again, and this time let it finish the update.

@drinkcat: this hits most people who installed the audio target early on; is there a good way to detect the situation and fix it, or should we just wait it out? If it's worth handling, go ahead and open a new bug instead of continuing the discussion here.

Owner

dnschneid commented Dec 10, 2013

@DennisLfromGA: try entering the chroot, saying "n" to finishing the update, then running sudo dpkg -r libsbc1 libsbc1:i386, exit the chroot, enter it again, and this time let it finish the update.

@drinkcat: this hits most people who installed the audio target early on; is there a good way to detect the situation and fix it, or should we just wait it out? If it's worth handling, go ahead and open a new bug instead of continuing the discussion here.

@DennisLfromGA

This comment has been minimized.

Show comment
Hide comment
@DennisLfromGA

DennisLfromGA Dec 10, 2013

Collaborator

Many thanx David, that worked!
I removed the packages, updated & then updated again specifying the
'extension' target and all is well. :)

After getting your email, it reminded of another similar
situationhttps://github.com/dnschneid/crouton/issues/506#issuecomment-30114626that
@drinkcat remedied for artemkolotilkin. I think perhaps 'beer and/or
cookies' are definitely deserved... :)

Thanx again.

On Tue, Dec 10, 2013 at 1:49 PM, David Schneider
notifications@github.comwrote:

@DennisLfromGA https://github.com/DennisLfromGA: try entering the
chroot, saying "n" to finishing the update, then running sudo dpkg -r
libsbc1 libsbc1:i386, exit the chroot, enter it again, and this time let
it finish the update.

@drinkcat https://github.com/drinkcat: this hits most people who
installed the audio target early on; is there a good way to detect the
situation and fix it, or should we just wait it out? If it's worth
handling, go ahead and open a new bug instead of continuing the discussion
here.


Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/pull/144#issuecomment-30255864
.

DennyL@GMail

Collaborator

DennisLfromGA commented Dec 10, 2013

Many thanx David, that worked!
I removed the packages, updated & then updated again specifying the
'extension' target and all is well. :)

After getting your email, it reminded of another similar
situationhttps://github.com/dnschneid/crouton/issues/506#issuecomment-30114626that
@drinkcat remedied for artemkolotilkin. I think perhaps 'beer and/or
cookies' are definitely deserved... :)

Thanx again.

On Tue, Dec 10, 2013 at 1:49 PM, David Schneider
notifications@github.comwrote:

@DennisLfromGA https://github.com/DennisLfromGA: try entering the
chroot, saying "n" to finishing the update, then running sudo dpkg -r
libsbc1 libsbc1:i386, exit the chroot, enter it again, and this time let
it finish the update.

@drinkcat https://github.com/drinkcat: this hits most people who
installed the audio target early on; is there a good way to detect the
situation and fix it, or should we just wait it out? If it's worth
handling, go ahead and open a new bug instead of continuing the discussion
here.


Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/pull/144#issuecomment-30255864
.

DennyL@GMail

@tedm

This comment has been minimized.

Show comment
Hide comment
@tedm

tedm Dec 23, 2013

Contributor

looking forward to clipboard sync, was using chrome os browser, but a web app couldn't detect that it was in chrome os on a chrome book and just wouldn't run. I went to chromium on crouton, and it detected that it wasn't on a supported platform, but allowed the user to email the output. Could be that it just didn't understand the dev channel browser, and might work ok on chromebooks on stable channel.

Contributor

tedm commented Dec 23, 2013

looking forward to clipboard sync, was using chrome os browser, but a web app couldn't detect that it was in chrome os on a chrome book and just wouldn't run. I went to chromium on crouton, and it detected that it wasn't on a supported platform, but allowed the user to email the output. Could be that it just didn't understand the dev channel browser, and might work ok on chromebooks on stable channel.

@DennisLfromGA

This comment has been minimized.

Show comment
Hide comment
@DennisLfromGA

DennisLfromGA Dec 23, 2013

Collaborator

@ted, Have you added the 'extention' target in your chroots and the 'crouton
integration extension' your browser? You can do that with an update '... -t
extension -u', clipboard sync is working for me.

On Mon, Dec 23, 2013 at 1:32 PM, tedm notifications@github.com wrote:

looking forward to clipboard sync, was using chrome os browser, but a web
app couldn't detect that it was in chrome os on a chrome book and just
wouldn't run. I went to chromium on crouton, and it detected that it wasn't
on a supported platform, but allowed the user to email the output. Could be
that it just didn't understand the dev channel browser, and might work ok
on chromebooks on stable channel.


Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/pull/144#issuecomment-31135647
.

DennyL@GMail

Collaborator

DennisLfromGA commented Dec 23, 2013

@ted, Have you added the 'extention' target in your chroots and the 'crouton
integration extension' your browser? You can do that with an update '... -t
extension -u', clipboard sync is working for me.

On Mon, Dec 23, 2013 at 1:32 PM, tedm notifications@github.com wrote:

looking forward to clipboard sync, was using chrome os browser, but a web
app couldn't detect that it was in chrome os on a chrome book and just
wouldn't run. I went to chromium on crouton, and it detected that it wasn't
on a supported platform, but allowed the user to email the output. Could be
that it just didn't understand the dev channel browser, and might work ok
on chromebooks on stable channel.


Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/pull/144#issuecomment-31135647
.

DennyL@GMail

@tedm

This comment has been minimized.

Show comment
Hide comment
@tedm

tedm Dec 24, 2013

Contributor

@DennisLfromGA Thanks Dennis, no I haven't tried the 'extention' target yet, but hope to try it, along with the new targets or names over the holidays.

Contributor

tedm commented Dec 24, 2013

@DennisLfromGA Thanks Dennis, no I haven't tried the 'extention' target yet, but hope to try it, along with the new targets or names over the holidays.

@tedm

This comment has been minimized.

Show comment
Hide comment
@tedm

tedm Dec 25, 2013

Contributor

@DennisLfromGA and everyone working on and helping with Crouton - Happy Holidays!!

Dennis - I ran apt-get update, and apt-get upgrade a few days ago, and was prompted to run apt-get autoremove on a few packages which I did. The chroot wouldn't come up again, it couldn't start the x server.

I deleted the chroot, and downloaded the latest crouton, I just want to install the xfce, -extension, chromium (is it still removed? that is silly!), so this should go fine, but where is the "desktop-xxxx" target or is it nomenclature only?

When I type sudo sh -e ~/Downloads/crouton -t help it only shows a long list of targets that mostly aren't going to run on the ARM, or very inefficiently if they do.

Not sure why a user running on the arm needs to see touch screen targets, haswell, x86, and other things that will just crap out on an ARM cpu...

Thanks for any tips.

Contributor

tedm commented Dec 25, 2013

@DennisLfromGA and everyone working on and helping with Crouton - Happy Holidays!!

Dennis - I ran apt-get update, and apt-get upgrade a few days ago, and was prompted to run apt-get autoremove on a few packages which I did. The chroot wouldn't come up again, it couldn't start the x server.

I deleted the chroot, and downloaded the latest crouton, I just want to install the xfce, -extension, chromium (is it still removed? that is silly!), so this should go fine, but where is the "desktop-xxxx" target or is it nomenclature only?

When I type sudo sh -e ~/Downloads/crouton -t help it only shows a long list of targets that mostly aren't going to run on the ARM, or very inefficiently if they do.

Not sure why a user running on the arm needs to see touch screen targets, haswell, x86, and other things that will just crap out on an ARM cpu...

Thanks for any tips.

@DennisLfromGA

This comment has been minimized.

Show comment
Hide comment
@DennisLfromGA

DennisLfromGA Dec 26, 2013

Collaborator

@ted,
I don't know why updating, upgrading, an auto-removing in the chroot broke
it, it shouln't have. I've never had a problem by downloading the latest
version of crouton and using it to do the updating or adding targets, that
seems like the best, most compatible way to do updates.
As far as the 'desktop-xxxx' targets, crouton hasn't merged that
branchhttps://github.com/dnschneid/crouton/tree/desktopsyet, they're
waiting on more testers and feedback first. This branch loads
the full desktop like ubuntu, kubuntu, lubuntu, xubuntu instead of just
the -minimal packages so they're much bigger - and take longer to install.
You can help out if you want by downloading it
herehttps://docs.google.com/uc?export=download&id=0B1QUtoJwc9L3a05ZcFNkMFpnRTQand
checking it out yourself.

On Wed, Dec 25, 2013 at 1:45 PM, tedm notifications@github.com wrote:

@DennisLfromGA https://github.com/DennisLfromGA and everyone working on
and helping with Crouton - Happy Holidays!!

Dennis - I ran apt-get update, and apt-get upgrade a few days ago, and was
prompted to run apt-get autoremove on a few packages which I did. The
chroot wouldn't come up again, it couldn't start the x server.

I deleted the chroot, and downloaded the latest crouton, I just want to
install the xfce, -extension, chromium (is it still removed? that is
silly!), so this should go fine, but where is the "desktop-xxxx" target or
is it nomenclature only?

When I type sudo sh -e ~/Downloads/crouton -t help it only shows a long
list of targets that mostly aren't going to run on the ARM, or very
inefficiently if they do.

Not sure why a user running on the arm needs to see touch screen targets,
haswell, x86, and other things that will just crap out on an ARM cpu...

Thanks for any tips.


Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/pull/144#issuecomment-31203506
.

DennyL@GMail

Collaborator

DennisLfromGA commented Dec 26, 2013

@ted,
I don't know why updating, upgrading, an auto-removing in the chroot broke
it, it shouln't have. I've never had a problem by downloading the latest
version of crouton and using it to do the updating or adding targets, that
seems like the best, most compatible way to do updates.
As far as the 'desktop-xxxx' targets, crouton hasn't merged that
branchhttps://github.com/dnschneid/crouton/tree/desktopsyet, they're
waiting on more testers and feedback first. This branch loads
the full desktop like ubuntu, kubuntu, lubuntu, xubuntu instead of just
the -minimal packages so they're much bigger - and take longer to install.
You can help out if you want by downloading it
herehttps://docs.google.com/uc?export=download&id=0B1QUtoJwc9L3a05ZcFNkMFpnRTQand
checking it out yourself.

On Wed, Dec 25, 2013 at 1:45 PM, tedm notifications@github.com wrote:

@DennisLfromGA https://github.com/DennisLfromGA and everyone working on
and helping with Crouton - Happy Holidays!!

Dennis - I ran apt-get update, and apt-get upgrade a few days ago, and was
prompted to run apt-get autoremove on a few packages which I did. The
chroot wouldn't come up again, it couldn't start the x server.

I deleted the chroot, and downloaded the latest crouton, I just want to
install the xfce, -extension, chromium (is it still removed? that is
silly!), so this should go fine, but where is the "desktop-xxxx" target or
is it nomenclature only?

When I type sudo sh -e ~/Downloads/crouton -t help it only shows a long
list of targets that mostly aren't going to run on the ARM, or very
inefficiently if they do.

Not sure why a user running on the arm needs to see touch screen targets,
haswell, x86, and other things that will just crap out on an ARM cpu...

Thanks for any tips.


Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/pull/144#issuecomment-31203506
.

DennyL@GMail

@tedm

This comment has been minimized.

Show comment
Hide comment
@tedm

tedm Dec 26, 2013

Contributor

Thanks Dennis, if you can provide the syntax and version of crouton (if not latest), I will try the desktop-xfce target.

The issue I've been having with both dev channel chromeos, and oddly with the last xfce precise chroot was that the alt-shift or ctrl-shift (ctrl-x never works) wasn't letting me do a clean -X commands in the nano editor. I will write that up when I get a new xfce chroot.

So would it be crosh / shell / sudo sh -e ~/Downloads/crouton -t desktop-xfce, chromium, extensions to get a precise xfce chroot while testing the extensions and having the chromium browser in the chroot?

Thanks!

Contributor

tedm commented Dec 26, 2013

Thanks Dennis, if you can provide the syntax and version of crouton (if not latest), I will try the desktop-xfce target.

The issue I've been having with both dev channel chromeos, and oddly with the last xfce precise chroot was that the alt-shift or ctrl-shift (ctrl-x never works) wasn't letting me do a clean -X commands in the nano editor. I will write that up when I get a new xfce chroot.

So would it be crosh / shell / sudo sh -e ~/Downloads/crouton -t desktop-xfce, chromium, extensions to get a precise xfce chroot while testing the extensions and having the chromium browser in the chroot?

Thanks!

@DennisLfromGA

This comment has been minimized.

Show comment
Hide comment
@DennisLfromGA

DennisLfromGA Dec 26, 2013

Collaborator

@ted, You may not have noticed but I gave you the links to the desktop
branch earlier.
Download the 'crouton-desktops' script from
herehttps://docs.google.com/uc?export=download&id=0B1QUtoJwc9L3a05ZcFNkMFpnRTQ,
then run it similarly to the way you would crouton. You can get a list of
releases with 'crouton-desktops -r list' and a list of desktops & sizes
with 'crouton-desktops -t list'.

If you want to use the xfce desktop on a quantal release and name it
quantal-desktops and experiment with the clipboard sync extension for
example, then it would be -

sudo sh -e ~/Downloads/crouton-desktops -r quantal -n quantal-desktops

-t extension,xfce-desktop

Hope this helps...

On Thu, Dec 26, 2013 at 3:38 PM, tedm notifications@github.com wrote:

Thanks Dennis, if you can provide the syntax and version of crouton (if
not latest), I will try the desktop-xfce target.

The issue I've been having with both dev channel chromeos, and oddly with
the last xfce precise chroot was that the alt-shift or ctrl-shift (ctrl-x
never works) wasn't letting me do a clean -X commands in the nano editor. I
will write that up when I get a new xfce chroot.

So would it be crosh / shell / sudo sh -e ~/Downloads/crouton -t
desktop-xfce, chromium, extensions to get a precise xfce chroot while
testing the extensions and having the chromium browser in the chroot?

Thanks!


Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/pull/144#issuecomment-31234862
.

DennyL@GMail

Collaborator

DennisLfromGA commented Dec 26, 2013

@ted, You may not have noticed but I gave you the links to the desktop
branch earlier.
Download the 'crouton-desktops' script from
herehttps://docs.google.com/uc?export=download&id=0B1QUtoJwc9L3a05ZcFNkMFpnRTQ,
then run it similarly to the way you would crouton. You can get a list of
releases with 'crouton-desktops -r list' and a list of desktops & sizes
with 'crouton-desktops -t list'.

If you want to use the xfce desktop on a quantal release and name it
quantal-desktops and experiment with the clipboard sync extension for
example, then it would be -

sudo sh -e ~/Downloads/crouton-desktops -r quantal -n quantal-desktops

-t extension,xfce-desktop

Hope this helps...

On Thu, Dec 26, 2013 at 3:38 PM, tedm notifications@github.com wrote:

Thanks Dennis, if you can provide the syntax and version of crouton (if
not latest), I will try the desktop-xfce target.

The issue I've been having with both dev channel chromeos, and oddly with
the last xfce precise chroot was that the alt-shift or ctrl-shift (ctrl-x
never works) wasn't letting me do a clean -X commands in the nano editor. I
will write that up when I get a new xfce chroot.

So would it be crosh / shell / sudo sh -e ~/Downloads/crouton -t
desktop-xfce, chromium, extensions to get a precise xfce chroot while
testing the extensions and having the chromium browser in the chroot?

Thanks!


Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/pull/144#issuecomment-31234862
.

DennyL@GMail

@tedm

This comment has been minimized.

Show comment
Hide comment
@tedm

tedm Dec 26, 2013

Contributor

Thanks @DennisLfromGA - it is installing now. The 'crouton-desktops -r list' gave a permission denied, even when run as root (crosh / shell / sudo su ) # - whoami - root, it has 744 perms.

Look forward to trying it once installed.

Contributor

tedm commented Dec 26, 2013

Thanks @DennisLfromGA - it is installing now. The 'crouton-desktops -r list' gave a permission denied, even when run as root (crosh / shell / sudo su ) # - whoami - root, it has 744 perms.

Look forward to trying it once installed.

@DennisLfromGA

This comment has been minimized.

Show comment
Hide comment
@DennisLfromGA

DennisLfromGA Dec 26, 2013

Collaborator

@ted, Sorry, I've got mine mounted r/w, I forgot. You'll have to use 'sh'
to execute it.

On Thu, Dec 26, 2013 at 5:32 PM, tedm notifications@github.com wrote:

Thanks @DennisLfromGA https://github.com/DennisLfromGA - it is
installing now. The 'crouton-desktops -r list' gave a permission denied,
even when run as root (crosh / shell / sudo su ) # - whoami - root, it has
744 perms.

Look forward to trying it once installed.


Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/pull/144#issuecomment-31238692
.

DennyL@GMail

Collaborator

DennisLfromGA commented Dec 26, 2013

@ted, Sorry, I've got mine mounted r/w, I forgot. You'll have to use 'sh'
to execute it.

On Thu, Dec 26, 2013 at 5:32 PM, tedm notifications@github.com wrote:

Thanks @DennisLfromGA https://github.com/DennisLfromGA - it is
installing now. The 'crouton-desktops -r list' gave a permission denied,
even when run as root (crosh / shell / sudo su ) # - whoami - root, it has
744 perms.

Look forward to trying it once installed.


Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/pull/144#issuecomment-31238692
.

DennyL@GMail

@tedm

This comment has been minimized.

Show comment
Hide comment
@tedm

tedm Dec 27, 2013

Contributor

extensions not working on Samsung arm with crouton d/l from today,

install was crosh / shell:

sudo sh -e ~/Downloads/crouton -t extensions,chromium,xfce

Is it possible that extensions wants/needs something post precise, or does not work on the arm ?

errors were:

chronos@localhost / $ sudo startxfce4
Entering /usr/local/chroots/precise...
/usr/bin/startxfce4: Starting X server

[dix] Could not init font path element /usr/share/fonts/X11/misc, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/Type1, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list!
[dix] Could not init font path element /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, removing from list!
[xkb] Can't rename /tmp/file0ZMZsb to /tmp/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm, error: Operation not permitted
[xkb] Can't rename /tmp/fileEVh4mK to /tmp/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm, error: Operation not permitted
XKB: Failed to compile keymap
Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config.

Fatal server error:
Failed to activate core devices.
Timeout waiting for extension to connect.
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 20 (X_GetProperty)
Resource id in failed request: 0xa00002
Serial number of failed request: 13
Current serial number in output stream: 13
/usr/bin/xinit: giving up
/usr/bin/xinit: unable to connect to X server: No such file or directory
/usr/bin/xinit: server error
Unmounting /usr/local/chroots/precise...
Sending SIGTERM to processes under /usr/local/chroots/precise...
Sending SIGKILL to processes under /usr/local/chroots/precise...
Sending SIGKILL to processes under /usr/local/chroots/precise...

Contributor

tedm commented Dec 27, 2013

extensions not working on Samsung arm with crouton d/l from today,

install was crosh / shell:

sudo sh -e ~/Downloads/crouton -t extensions,chromium,xfce

Is it possible that extensions wants/needs something post precise, or does not work on the arm ?

errors were:

chronos@localhost / $ sudo startxfce4
Entering /usr/local/chroots/precise...
/usr/bin/startxfce4: Starting X server

[dix] Could not init font path element /usr/share/fonts/X11/misc, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/Type1, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list!
[dix] Could not init font path element /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, removing from list!
[xkb] Can't rename /tmp/file0ZMZsb to /tmp/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm, error: Operation not permitted
[xkb] Can't rename /tmp/fileEVh4mK to /tmp/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm, error: Operation not permitted
XKB: Failed to compile keymap
Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config.

Fatal server error:
Failed to activate core devices.
Timeout waiting for extension to connect.
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 20 (X_GetProperty)
Resource id in failed request: 0xa00002
Serial number of failed request: 13
Current serial number in output stream: 13
/usr/bin/xinit: giving up
/usr/bin/xinit: unable to connect to X server: No such file or directory
/usr/bin/xinit: server error
Unmounting /usr/local/chroots/precise...
Sending SIGTERM to processes under /usr/local/chroots/precise...
Sending SIGKILL to processes under /usr/local/chroots/precise...
Sending SIGKILL to processes under /usr/local/chroots/precise...

@DennisLfromGA

This comment has been minimized.

Show comment
Hide comment
@DennisLfromGA

DennisLfromGA Dec 27, 2013

Collaborator

Ted, just wondering if you installed the 'crouton integration' piece on the
ChromeOS side??? There's a 'Tip' at the end of the setup that says:

"You must install the Chromium OS extension for integration with

crouton to work.

The extension is available here: http://goo.gl/OVQOEt"

It can get overlooked, especially if you're not expecting it.

On Fri, Dec 27, 2013 at 2:57 AM, tedm notifications@github.com wrote:

extensions not working on Samsung arm with crouton d/l from today,

install was crosh / shell:

sudo sh -e ~/Downloads/crouton-desktops -t extensions,chromium,xfce

Is it possible that extensions wants/needs something post precise, or does
not work on the arm ?

errors were:

chronos@localhost / $ sudo startxfce4
Entering /usr/local/chroots/precise...
/usr/bin/startxfce4: Starting X server

[dix] Could not init font path element /usr/share/fonts/X11/misc, removing
from list!
[dix] Could not init font path element /usr/share/fonts/X11/cyrillic,
removing from list!
[dix] Could not init font path element
/usr/share/fonts/X11/100dpi/:unscaled, removing from list!
[dix] Could not init font path element
/usr/share/fonts/X11/75dpi/:unscaled, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/Type1,
removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/100dpi,
removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/75dpi,
removing from list!
[dix] Could not init font path element
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, removing from list!
[xkb] Can't rename /tmp/file0ZMZsb to
/tmp/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm, error: Operation
not permitted
[xkb] Can't rename /tmp/fileEVh4mK to
/tmp/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm, error: Operation
not permitted
XKB: Failed to compile keymap
Keyboard initialization failed. This could be a missing or incorrect setup
of xkeyboard-config.

Fatal server error:
Failed to activate core devices.
Timeout waiting for extension to connect.
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 20 (X_GetProperty)
Resource id in failed request: 0xa00002
Serial number of failed request: 13
Current serial number in output stream: 13
/usr/bin/xinit: giving up
/usr/bin/xinit: unable to connect to X server: No such file or directory
/usr/bin/xinit: server error
Unmounting /usr/local/chroots/precise...
Sending SIGTERM to processes under /usr/local/chroots/precise...
Sending SIGKILL to processes under /usr/local/chroots/precise...
Sending SIGKILL to processes under /usr/local/chroots/precise...


Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/pull/144#issuecomment-31251568
.

DennyL@GMail

Collaborator

DennisLfromGA commented Dec 27, 2013

Ted, just wondering if you installed the 'crouton integration' piece on the
ChromeOS side??? There's a 'Tip' at the end of the setup that says:

"You must install the Chromium OS extension for integration with

crouton to work.

The extension is available here: http://goo.gl/OVQOEt"

It can get overlooked, especially if you're not expecting it.

On Fri, Dec 27, 2013 at 2:57 AM, tedm notifications@github.com wrote:

extensions not working on Samsung arm with crouton d/l from today,

install was crosh / shell:

sudo sh -e ~/Downloads/crouton-desktops -t extensions,chromium,xfce

Is it possible that extensions wants/needs something post precise, or does
not work on the arm ?

errors were:

chronos@localhost / $ sudo startxfce4
Entering /usr/local/chroots/precise...
/usr/bin/startxfce4: Starting X server

[dix] Could not init font path element /usr/share/fonts/X11/misc, removing
from list!
[dix] Could not init font path element /usr/share/fonts/X11/cyrillic,
removing from list!
[dix] Could not init font path element
/usr/share/fonts/X11/100dpi/:unscaled, removing from list!
[dix] Could not init font path element
/usr/share/fonts/X11/75dpi/:unscaled, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/Type1,
removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/100dpi,
removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/75dpi,
removing from list!
[dix] Could not init font path element
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, removing from list!
[xkb] Can't rename /tmp/file0ZMZsb to
/tmp/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm, error: Operation
not permitted
[xkb] Can't rename /tmp/fileEVh4mK to
/tmp/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm, error: Operation
not permitted
XKB: Failed to compile keymap
Keyboard initialization failed. This could be a missing or incorrect setup
of xkeyboard-config.

Fatal server error:
Failed to activate core devices.
Timeout waiting for extension to connect.
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 20 (X_GetProperty)
Resource id in failed request: 0xa00002
Serial number of failed request: 13
Current serial number in output stream: 13
/usr/bin/xinit: giving up
/usr/bin/xinit: unable to connect to X server: No such file or directory
/usr/bin/xinit: server error
Unmounting /usr/local/chroots/precise...
Sending SIGTERM to processes under /usr/local/chroots/precise...
Sending SIGKILL to processes under /usr/local/chroots/precise...
Sending SIGKILL to processes under /usr/local/chroots/precise...


Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/pull/144#issuecomment-31251568
.

DennyL@GMail

@AF9210

This comment has been minimized.

Show comment
Hide comment
@AF9210

AF9210 Dec 27, 2013

thanks Dennis :) didn't see that in the Wiki ;)

AF9210 commented Dec 27, 2013

thanks Dennis :) didn't see that in the Wiki ;)

@tedm

This comment has been minimized.

Show comment
Hide comment
@tedm

tedm Dec 27, 2013

Contributor

Thanks @DennisLfromGA no, I did not install the Chromium extension but I don't think that's why the crouton-desktop failed to install on the arm.

A regular install of just crouton with -t chromium,xfce also fails. I think support dropped off for the ARM systems and/or precise, will try quantal or raring next without chromium, just xfce, after crouton regular starts working, I will try the crouton-desktops again.

errors with using sh -e ~/Downloads/crouton -t chromium,xfce

Done! You can enter the chroot using enter-chroot.
chronos@localhost / $ sudo startxfce4
Entering /usr/local/chroots/precise...
/usr/bin/startxfce4: Starting X server

[dix] Could not init font path element /usr/share/fonts/X11/misc, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/Type1, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list!
[dix] Could not init font path element /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, removing from list!
[xkb] Can't rename /tmp/file0PaJzL to /tmp/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm, error: Operation not permitted
[xkb] Can't rename /tmp/filewthJOu to /tmp/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm, error: Operation not permitted
XKB: Failed to compile keymap
Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config.

Fatal server error:
Failed to activate core devices.
/usr/bin/xinit: giving up
/usr/bin/xinit: unable to connect to X server: No such file or directory
/usr/bin/xinit: server error
Unmounting /usr/local/chroots/precise...
chronos@localhost / $

Contributor

tedm commented Dec 27, 2013

Thanks @DennisLfromGA no, I did not install the Chromium extension but I don't think that's why the crouton-desktop failed to install on the arm.

A regular install of just crouton with -t chromium,xfce also fails. I think support dropped off for the ARM systems and/or precise, will try quantal or raring next without chromium, just xfce, after crouton regular starts working, I will try the crouton-desktops again.

errors with using sh -e ~/Downloads/crouton -t chromium,xfce

Done! You can enter the chroot using enter-chroot.
chronos@localhost / $ sudo startxfce4
Entering /usr/local/chroots/precise...
/usr/bin/startxfce4: Starting X server

[dix] Could not init font path element /usr/share/fonts/X11/misc, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/Type1, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list!
[dix] Could not init font path element /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, removing from list!
[xkb] Can't rename /tmp/file0PaJzL to /tmp/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm, error: Operation not permitted
[xkb] Can't rename /tmp/filewthJOu to /tmp/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm, error: Operation not permitted
XKB: Failed to compile keymap
Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config.

Fatal server error:
Failed to activate core devices.
/usr/bin/xinit: giving up
/usr/bin/xinit: unable to connect to X server: No such file or directory
/usr/bin/xinit: server error
Unmounting /usr/local/chroots/precise...
chronos@localhost / $

@dnschneid dnschneid referenced this pull request Dec 29, 2013

Closed

Webserver commands #558

@hsharrison

This comment has been minimized.

Show comment
Hide comment
@hsharrison

hsharrison Nov 18, 2014

Just curious, is there any way to get this to work if I'm running a chroot's window manager within ChromeOS rather than starting a full-fledged DE, as in #1? The Chrome extension doesn't recognize a running chroot.

I'm hoping maybe there's a script I have to run manually to get this going (analagous to running croutonwheel to get scrolling working), but I'm also prepared for the answer that it's just not possible in the current implementation.

Just curious, is there any way to get this to work if I'm running a chroot's window manager within ChromeOS rather than starting a full-fledged DE, as in #1? The Chrome extension doesn't recognize a running chroot.

I'm hoping maybe there's a script I have to run manually to get this going (analagous to running croutonwheel to get scrolling working), but I'm also prepared for the answer that it's just not possible in the current implementation.

@drinkcat

This comment has been minimized.

Show comment
Hide comment
@drinkcat

drinkcat Nov 18, 2014

Collaborator

@hsharrison : It's not tested extensively, but running croutonclip, and having the extension installed, should just work (have a look at the log of the extension to confirm that the clipboard data is passed around).

Collaborator

drinkcat commented Nov 18, 2014

@hsharrison : It's not tested extensively, but running croutonclip, and having the extension installed, should just work (have a look at the log of the extension to confirm that the clipboard data is passed around).

@hsharrison

This comment has been minimized.

Show comment
Hide comment
@hsharrison

hsharrison Nov 18, 2014

Ah, I should have known it was that simple.

On first pass, here's the behavior I'm getting: any time I copy something in ChromeOS, it gets appended to the clipboard that the chroot windows are using, so when I paste in a chroot window, I get everything I've ever copied in ChromeOS since starting croutonclip. Once I copy in a chroot window, a subsequent paste will be correct (but not synced back to ChromeOS). Copy something in ChromeOS again, and then pasting in the chroot goes back to the previously copied strings all together.

I'll play around with it more and check out the logs. Is there a better place to discuss this, or should I open a new issue, or keep posting here?

Ah, I should have known it was that simple.

On first pass, here's the behavior I'm getting: any time I copy something in ChromeOS, it gets appended to the clipboard that the chroot windows are using, so when I paste in a chroot window, I get everything I've ever copied in ChromeOS since starting croutonclip. Once I copy in a chroot window, a subsequent paste will be correct (but not synced back to ChromeOS). Copy something in ChromeOS again, and then pasting in the chroot goes back to the previously copied strings all together.

I'll play around with it more and check out the logs. Is there a better place to discuss this, or should I open a new issue, or keep posting here?

@drinkcat

This comment has been minimized.

Show comment
Hide comment
@drinkcat

drinkcat Nov 18, 2014

Collaborator

@hsharrison : Weird. Please open a new issue yes.

Collaborator

drinkcat commented Nov 18, 2014

@hsharrison : Weird. Please open a new issue yes.

@kiko

This comment has been minimized.

Show comment
Hide comment
@kiko

kiko Nov 21, 2014

@hsharrison : If I understand correctly, Isn't this a same issue as I mentioned at #144 (comment)?
Patch that worked with old croutonclip is here: https://gist.github.com/kiko/6724792

@drinkcat Can you add this function to the current version of croutonclip?

kiko commented Nov 21, 2014

@hsharrison : If I understand correctly, Isn't this a same issue as I mentioned at #144 (comment)?
Patch that worked with old croutonclip is here: https://gist.github.com/kiko/6724792

@drinkcat Can you add this function to the current version of croutonclip?

@hsharrison

This comment has been minimized.

Show comment
Hide comment
@hsharrison

hsharrison Nov 22, 2014

Ah, thank you. I noticed also that some (similar?) changes were necessary in croutonwheel to make it properly detect aura windows (using xwininfo instead of croutonwmtools). It would be nice to include this somehow also. However I'm not sure what the best way is, are these modifications compatible with using xephyr to launch a full DE? If not, maybe there could be a target designed for running a second WM alongside aura? Or maybe host-x11 or something like it could launch these modified version of croutonclip and croutonwheel.

I'm able to hack around by trial and error but I don't have enough of the big picture to know what the best approach would be for everyone. I'd be willing to give a shot at contributing if I had some guidance on the best approach to take, though. Here's a gist. I forget where I picked up these modifications, I didn't come up with them myself although I did tweak them a bit.

Ah, thank you. I noticed also that some (similar?) changes were necessary in croutonwheel to make it properly detect aura windows (using xwininfo instead of croutonwmtools). It would be nice to include this somehow also. However I'm not sure what the best way is, are these modifications compatible with using xephyr to launch a full DE? If not, maybe there could be a target designed for running a second WM alongside aura? Or maybe host-x11 or something like it could launch these modified version of croutonclip and croutonwheel.

I'm able to hack around by trial and error but I don't have enough of the big picture to know what the best approach would be for everyone. I'd be willing to give a shot at contributing if I had some guidance on the best approach to take, though. Here's a gist. I forget where I picked up these modifications, I didn't come up with them myself although I did tweak them a bit.

@drinkcat

This comment has been minimized.

Show comment
Hide comment
@drinkcat

drinkcat Nov 22, 2014

Collaborator

@kiko : Your patch was integrated into croutonclip (probably with some modifications, IIRC the code was refactored). It does look like something is broken, though.

@hsharrison : I don't understand why you had to replace croutonwmtools by xwininfo. Can you provide the output of both commands and show why the latter is working and not the former?

With regards to croutonclip, I would set VERBOSE=1, and maybe launch croutonclip with sh -e -x .../croutonclip, so you get a trace of what commands are executed.

Collaborator

drinkcat commented Nov 22, 2014

@kiko : Your patch was integrated into croutonclip (probably with some modifications, IIRC the code was refactored). It does look like something is broken, though.

@hsharrison : I don't understand why you had to replace croutonwmtools by xwininfo. Can you provide the output of both commands and show why the latter is working and not the former?

With regards to croutonclip, I would set VERBOSE=1, and maybe launch croutonclip with sh -e -x .../croutonclip, so you get a trace of what commands are executed.

@hsharrison

This comment has been minimized.

Show comment
Hide comment
@hsharrison

hsharrison Nov 22, 2014

Sure.

$ croutonwmtools list ni
Unknown 10485802
Unknown 10485774

$ xwininfo -name aura_root_0

xwininfo: Window id: 0x200004 "aura_root_0"

  Absolute upper-left X:  0
  Absolute upper-left Y:  0
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 1366
  Height: 768
  Depth: 24
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +0+0  -0+0  -0-0  +0-0
  -geometry 1366x768+0+0

Sure.

$ croutonwmtools list ni
Unknown 10485802
Unknown 10485774

$ xwininfo -name aura_root_0

xwininfo: Window id: 0x200004 "aura_root_0"

  Absolute upper-left X:  0
  Absolute upper-left Y:  0
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 1366
  Height: 768
  Depth: 24
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +0+0  -0+0  -0-0  +0-0
  -geometry 1366x768+0+0
@kiko

This comment has been minimized.

Show comment
Hide comment
@kiko

kiko Dec 6, 2014

@drinkcat : How does croutonclip determine the window change (ie. xephyr) now?

kiko commented Dec 6, 2014

@drinkcat : How does croutonclip determine the window change (ie. xephyr) now?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment